Uploaded image for project: 'GPII - Global Public Inclusive Infrastructure'
  1. GPII - Global Public Inclusive Infrastructure
  2. GPII-3193

Reform LifecycleManager session support to provide "noUser" session which is always logged on

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: Cloud 1
    • Fix Version/s: None
    • Component/s: Lifecycle Manager
    • Labels:
      None
    • Story Points:
      6

      Description

      To support the required QSS functionality as part of GPII-3088, we need to provide an "always active" session in the LifecycleManager whose state may always be addressed in order to change the local system settings, even if no user is keyed in to the system.
      A straightforward way to implement this session is to allocate a special "noUser" key with a hardwired empty preference set which will be
      i) keyed in on to the system at startup,
      ii) and then under our normal semantic keyed out whenever any genuine user is keyed in, but then
      iii) will be immediately keyed in again whenever no other user is keyed in.

      This will change a lot of our existing semantic so we will need to take care of some special cases - although in practice we should be able to get away with claiming for most purposes that this really is a genuine user session since all clients who might be interested (e.g. the PSP/QSS itself) will have to become aware of this special semantic otherwise they will not be able to gain access to the functionality which it is meant to support. So we might well go through all the normal processes of matchmaking, etc. even if they end up being noops.

      This would be a good time to clean up a long-standing annoyance in the LifecycleManager's architecture, in that LifecycleManagerSession is a dynamic component that in theory there could be multiple instances of. This is a leftover of a Cloud4All semantic where it was dreamed that a single local LifecycleManager might support multiple concurrent but unrelated user sessions. This will not be the case for the lifetime of the current project, so we should radically simplify this architecture so that LifecycleManagerSession is a straightforward single subcomponent. This will let us get rid of all the cumbersome "session indexing" implementation, and makes perfect sense with respect to the lifecycleManager's existing model containing "logonChange" which morally appeals to a singleton subcomponent in any case.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                cli@ocad.ca Cindy Qi Li
                Reporter:
                amb26 Antranig Basman
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: