Configuration > Site Maintenance

[ggeisler]

From the Administrative Dashboard Needs document:

Enable/disable a site maintenance banner, either manually or scheduled, so that I can easily display a time-sensitive message to users about system issues when they need to see it.

Enter and edit site maintenance banner contents, and I should be able to format text, embed links, etc., so that I can tailor the message and style its presentation.

Mockups

This is the simplest design that seems useful. Obviously we could provide more options (enable user to specify an end-date/time to turn off banner automatically, allow choice of banner background color, etc.), but perhaps this is enough to start with?

Three tabs: Schedule, Banner Content, Preview

Schedule Tab

For the "Future" controls, I assume we'd use the datepicker currently used by Sufia. If Sufia isn't already using a timepicker, maybe something like http://jonthornton.github.io/jquery-timepicker/ would work?

If Future is selected, both the date and time fields are required and must be later than the current date/time.

The timezone displayed should be the current user's timezone. We could make the timezone selectable as well, but again that is an extra customization option that seems unnecessary for a first version.

Banner Content Tab

For the text box, we'd ideally provide a text formatting bar rather than asking the user to use Markdown or something. I'm not sure if Sufia already uses a text formatting widget somewhere, but if not, adding one could also be useful for the About, Home, and Content blocks, I would think?

Preview Tab

Assumes we'll display the banner using the alert-info styling. Also, the mockup shows a Save button for this tab, but that is not relevant here. However, it might be handy to have that button labeled "Edit" instead, and redirect back to the Banner Content tab (just to give the user another way to get back to editing the banner content). Otherwise, I'd remove the bottom gray section with the Save button from this tab.

[hannahfrost]

Looks good, Gary

[cbeer]

How does this work in a multi-tenant environment? Is there any reason those administrators would need access to this feature?

[ggeisler]

Might not each tenant want the ability to customize their own message?

I might not fully understand the implications of the multi-tenant environment. It sounds like it would be helpful to for us to specify which features are not relevant to individual tenants in a multi-tenant environment.

[cbeer]

Maybe the sample message is confusing me (if you're not in control of the software update schedule or on the hook for systems administration, you probably wouldn't write a maintenance alert).

[ggeisler]

I see. Sure, that's a good point.

So a question to answer (could be applicable to other features in a multi-tenant scenario) is whether for features that are not likely to be relevant to a tenant in a multi-tenant environment, do we hide them from tenants, or leave them and assume tenants won't use things that have no use to them?

Hiding them is the best approach, if we're sure tenants won't need them. But that might bring up a question of whether we can reliably know things to hide programmatically based on the scenario, or whether we need an additional configuration feature for the administrator of a multi-tenant installation where that administrator can control what its tenants see. I haven't given any thought to potential special needs of the multi-tenant administrator yet.

[danhorst]

@ggeisler is this issue blocked until a decision has been made for multitenancy support or can it be implemented as specified?

[ggeisler]

@danhorst I think we could implement it as designed, and then if we decide that tenants in a multi-tenant environment shouldn't have access to the site maintenance configuration, we could simply prevent them from seeing/having access to the feature. So the current design would not be affected by the multi-tenant consideration, we'd just add a check in the code to determine which type the user is before making the feature visible.

It might be good to get @mjgiarlo's thoughts before beginning work on this, though, just to make sure I'm not missing something.

[mjgiarlo]

@ggeisler @danhorst I don't believe we've done any work yet on a superadministrator UI, where this could be done for all tenants at once. IOW, the only way to do this now without major feature work is to implement it on a per-tenant basis, which seems like not the best fit for this feature. So either we put cycles into defining the superadmin UI (for which we'll need tickets and novel design work), or we deprioritize this ticket until the former has been done. This is where I speculate that we should punt this until after the MVP is released. @hannahfrost @jcoyne other thoughts?

[hannahfrost]

+1 to deprioritizing this feature. I do wonder if there is an edge case where a single tenant in a multi-tenant hosted situation would like to have some control over making their system unavailable, like if they were majorly overhauling the metadata or permissions or look and feel, and wanted to keep users out of the system for some period? It might be helpful to ask folks who have more experience with hosting, to see if that kind of thing comes up. In any event, the site maintenance feature is of course relevant to those who intend to implement Hyku as a single tenant.

[mjgiarlo]

@hannahfrost :cool: !

I imagine there is an edge case there, but it's hard to care too much about it given there's not much ability to overhaul those things in the UI currently. Worth revisiting once we provide the sorts of feature that would qualify as an overhaul?