City Hall: shared data and remote support

Ideas shared (via Google Drive) folders to support remote data access & remote support.

Information in shared folders

Data File (i.e. daily log file):

• Currently, TT occasionally saves a copy of its log to the PUBLISH folder.
  • cautionary note: For same-day datafiles, TT reads tags lists (oversize, regular etc) from tags.txt, which may differ between prod (city hall) and support (JS/TG's desktops). (For datafiles whose date does not match today, TT gets the tags lists from the datafile.)

Echo file:

• Current branch development can have TT log every command and response to an echo file in PUBLISH. This allows remote support staff to look over the operators' shoulder for support & troubleshooting.

Config:

• local config is currently two files, neither of which gets overwritten by a git pull:
  • tags.txt: regular tags, oversize tags, retired tags
  • tt_conf.py: optionally overrides variables that are set in the base config, which is something like tt_default_conf.py.
• to see (or to change) these remotely, could:
  1. keep them on a shared Drive folder that support staff have r/w permissions on, and TT reads them from there
  2. keep them on a shared drive as above, and they are copied from there to TT folder by
  • an update command
  • .bash_profile
  • TT itself when it starts up -- yuck
  • TT's startup command. ⭐ Bonus here would be if it checked that existed, looked for diff, stated change....
• add a STARTUP_MESSAGE (or MOTD) var to tt_conf.py which TT would give on startup. This might say for example a supported version note or who knows what. Maybe this is better as a 'MOTD' file in config folder, which tt_conf simply looks for and inhales. Thus, coordinators could edit it themselves to say things like "stop using yellow tags" or "contact LJ not JP this weekend". But maybe that's silly -- after all ths workforce has Sling for all that.

Proposal

• currently Drive has a PUBLISH folder tracker_logs
• change this to:
  • tagtracker_shared
    • data (readable by staff and partners). Propose calling this 'data' rather than 'logs' because the 'echo' files are actually logs
    • config (readable by staff and partners; writable by coordinators and support staff)
    • reports (readable by staff and partners)
    • echo (readable and writable [so can delete things] by support and coordinators)
• replace PUBLISH with SHARED -> points to tagracker_shared
  • logs go into SHARED/data
  • consolidated logs database goes into SHARED/data
  • published reports go into SHARED/reports. Google Sites (or other web pages) would use this data.
  • config of course into SHARED/config
  • echo files go into SHARED/echo