Data/settings layout reorganization

[nmlorg]

Just to get unblocked, I'm going to propose and begin attempting to implement:

1. Don't touch Context.user, Context.chat, etc. at all. That can be addressed in a long-off followup.

2. Add a new Context.userinfo, Context.groupinfo, and Context.botinfo in metabot (probably in _MultiBotLoopDispatcher.__call__). This will expose data from BotConf in something like:

   • ctx.userinfo.data.language_code = users.USERID.language_code
   • ctx.userinfo.settings.timezone = bots.BOTNAME.users.USERID.timezone
   • ctx.groupinfo.data.title = groups.GROUPID.title
   • ctx.groupinfo.settings.timezone = bots.BOTNAME.groups.GROUPID.timezone
   • ctx.botinfo.data.xxx = bots.BOTNAME.data.xxx
   • ctx.botinfo.settings.telegram_token = bots.BOTNAME.settings.telegram_token

3. In pieces, move data/settings out of bots.BOTNAME.MODNAME into bots.BOTNAME.users/groups/data/settings. This means using the modconf parameter will be deprecated (and eventually removed), as will navigating through Context to find other data (like groupconf = ctx.bot.multibot.conf['bots'][ctx.bot.username]['moderator'][ctx.chat['id']]).

   • While this is happening, finalize and begin implementing the new field typing/ownership scheme, i.e. bots.BOTNAME.moderator.-100100100.dailytext -> bots.BOTNAME.groups.-100100100.daily_multiline, bots.BOTNAME.moderator.-100100100.daily -> bots.BOTNAME.groups.-100100100.daily_timeofday, etc.

4. For now, leave /admin alone. The long-term plan is still to change it to something like:

    >>> /admin
    [Bots | /admin bots]
    [Groups | /admin groups]
    [Users | /admin users]
   
    >>> /admin bots
    [BOTNAME | /admin bots BOTNAME]
    [OTHERBOT | /admin bots OTHERBOT]
    [Back | /admin]
   
    >>> /admin bots BOTNAME
    [Bot Settings | /admin bots BOTNAME bot]
    [Groups | /admin bots BOTNAME groups]
    [Users | /admin bots BOTNAME users]
   
    >>> /admin bots BOTNAME bot]
    [timezone | /admin bots BOTNAME bot timezone]
   
    >>> /admin bots BOTNAME bot timezone
    The current timezone is US/Pacific. Select a new one:
    [US/Central | /admin bots BOTNAME bot timezone US/Central]
    [US/Eastern | /admin bots BOTNAME bot timezone US/Eastern]
    [US/Mountain | /admin bots BOTNAME bot timezone US/Mountain]
    [US/Pacific | /admin bots BOTNAME bot timezone US/Pacific]
    [Back | /admin bots BOTNAME bot]
   
     ...
   
    >>> /admin bots BOTNAME groups
    [My First Group | /admin bots BOTNAME groups -100100100]
    [My Second Group | /admin bots BOTNAME groups -100200200]
    [Back | /admin bots BOTNAME]
   
    >>> /admin bots BOTNAME groups -100100100
    [greeting | /admin bots BOTNAME groups -100100100 greeting]
   
    >>> /admin bots BOTNAME groups -100100100 greeting
    The current greeting is "Welcome!". Type a new one:
   
     ...
   
    >>> /admin groups
    [My First Group | /admin groups -100100100]
    [My Second Group | /admin groups -100200200]
    [Back | /admin]
   
    >>> /admin groups -100100100
    [BOTNAME | /admin groups -100100100 bots BOTNAME]
    [OTHERBOT | /admin groups -100100100 bots OTHERBOT]
    [Back | /admin groups]
   
    >>> /admin groups -100100100 bots BOTNAME
    [greeting | /admin bots BOTNAME groups -100100100 greeting]
   
    >>> /admin groups -100100100 bots BOTNAME greeting
    The current greeting is "Welcome!". Type a new one:
   

   This probably means I should start with ctx.botinfo actually, then move to ctx.userinfo (which is only currently used via /events), then rebuild /admin coincident with beginning on ctx.groupinfo. However, it might also make sense to rename /admin to /legacy_admin and have a new placeholder /admin just provide an explanation of the work in progress (with a link to /legacy_admin).

[nmlorg]

Tentatively:  Leave /admin alone, but introduce a new /settings (alias /set) to be the new unified configurator. The example transcript above holds, just s#/admin#/set#g. The UI should be entirely modularized from the beginning:  /set will be something like metabot.modules.settings.default which will simply set msg.path('/set') and then call a new metabot.util.settingsui.menu(ctx, msg, bot=None, user=None, group=None). Issuing /set bots would pass into the same metabot.util.settingsui.menu(ctx, msg, bot=None, user=None, group=None), but menu would see the bots at the tail of msg.path and pull up a bot list, etc.  Issuing /events set would call info metabot.util.settingsui.menu(ctx, msg, bot=ctx.botinfo, user=ctx.userinfo, group=None) which would ignore msg.path and go right into the same UI as /set user or /set bots BOTNAME users USERID.

[nmlorg]

Two thoughts:

1. It would be simpler and possibly more accessible to reduce/eliminate the configure-any-bot-from-any-bot mechanism, so /set groups ... doesn't have that second menu to select a bot but goes right into setting greeting for just the bot you're conversing with. If anything, only the actual Bot Settings menu would have a bot selector (rather than going right into the current bot's settings) just to still be able to restart stopped bots.
2. Alternatively, we could build /set lock-step with Complex UI #32, i.e. the next step is to build the skeletal web UI, then as components are added to /set they're added to the web UI in the same commit. We could still have bot selection be the first step of UI entry (as in you message BOTNAME /set and it gives you a link directly to https://nmlorg.github.io/metabot/control.html#bot=BOTNAME); however, if you manage multiple groups, each with its own bot identity (which is true for me!), it might be convenient to have a unified group list across all bots (for both /set and control.html).

[nmlorg]

(See #93.)