Read-Only Mode

[mbarnett]

We want a simple way to enable and disable a read-only mode for ERA, in response to events like emergencies or upgrades that require us to freeze the data in a certain state, but don't require us to take the site down altogether.

I'm thinking we:

• Create a very small one-value table and model to indicate whether or not ERA is in read-only mode. Model just needs a couple of class methods (ReadonlyMode.enabled? and disabled?. Can probably make creating instances private and bury setting and clearing the mode behind class methods as well, for simplicity)
• Create two rake tasks to set the value to true or false
• Shortcut out of https://github.com/ualbertalib/jupiter/blob/integration_postmigration/app/controllers/application_controller.rb#L33 by returning nil immediately, and https://github.com/ualbertalib/jupiter/blob/integration_postmigration/app/controllers/application_controller.rb#L53 by doing nothing, if the read-only mode is true.
• Cache the check for, say, 1 minute so-as not to introduce more DB traffic on every single request.
• When the read-only mode is enabled, remove the log in button from the site
• When the read-only mode is enabled, display a banner on the site indicating that logins are temporarily disabled. This should work in addition to any notifications an admin has chosen to post (so both should be able to exist one atop the other simultaneously, or either by themselves)

[lagoan]

What if instead of having a single one value table we have a site wide configuration table (JupiterConfiguration or whatever) Where readOnlyMode is a value in that table.

This would allow to add more configuration values down the line and there is trivial extra work done to achieve this.

We could have a #readOnlyEnabled? method that can set the default value if it does not exist on the database.

[mbarnett]

In the spirit of YAGNI I really think that would be getting ahead of ourselves?

Right now we only have one use-case for this, and my philosophy is that you always want to have a minimum of two competing use-cases for something before you try to design a generic API around it.

I'd also be concerned about the lack of clarity between a "generic configuration" table and our general philosophy of config being something that is contributed by the environment (the 12 factor app approach, more or less). The need to make a read-only mode "dynamic configuration" is as much as anything a work-around for the extremely long deployment times imposed upon us any time we want to make a simple change to configuration; I don't think we should let this corner case inform our more general approach to configuration by building out a mechanism that in some sense encourages doing the wrong thing?

To pull directly from the Jupiter manifesto:

1. More than anything else, we should prefer to err on the side of simplicity. It is always easier to make a simple thing a bit more complex, than it is to simplify a complicated solution.
   corollary: We should prefer to ship something that only does 80% of what we need, and is missing the other 20%, rather than build something that solves 120% of our current needs by trying to imagine things we might want in the future. Attempts to anticipate the future rarely succeed, and often paint us into a corner.

[ConnorSheremeta]

What would be the best message for the banner on the top of the page for this? I have:

'Logins are currently disabled due to system maintenance, please try again later.'

The message should maybe have more or less information, it is dependant on the banner message that the admin will set before turning this mode on.

[mbarnett]

Lets run with that for now, and we can get final wording from Sean/Leah once they see it on Staging