This looks great! Do you think this feature will be available to admins through the GUI?

Hi @BPeuch - we'd plan to implement the management of this through the API initially.

For discussion as this enters development:

• Setting an expiration date as part of a message could be useful but also may be out of scope. Happy to discuss.
• For the ToU use case, we wouldn't want to display to users who had just signed up for an account (and just agreed with the terms of use). Not sure how to handle this.
• Can we track the dismissal of a banner (at least the session in which it occurred) in the DB?

From sprint planning

• @scolapasta mentioned moving banners outside of settings and set up some table for managing this
• This would potentially allow us to track this - which would be useful (20k-40k users means 20k-40k rows at least)
• @kcondon mentioned that there may be some overlap with notifications - it's some type of broadcast and we want to track if people have seen it (let's dig in this as we develop)
• Banners would be defined as automatically dismissible by new users (this is so a user that signs up for an account does not see the banner that terms of use are updated). As I mentioned during sprint planning, I think it's OK to have the updated ToU banner (for ex.) displayed to users who have just signed up for an account. Checked with @TaniaSchlatter and she is OK w/ it too.

Two user scenarios that represent Harvard use case:

1. Gary King (as existing depositor and data user) sees a message when he logs in to Harvard Dataverse, that terms of use have changed. He reads that by continuing to use the site, he is accepting the new terms. He sees that there is a link to the new terms that he can read if he wants. He checks out the new terms, which open in a new window. He closes the window, and, back on the Dataverse page, dismisses the message. The system tracks that Gary dismissed the message.
2. A new Dataverse user creates an account, accepting the (new) terms of use. On the Harvard Dataverse home page, the new user sees the same message. They dismiss the message. The system tracks that the new user dismissed the message, same as in the existing user scenario.

• we need to track user activity (dismissing the banner) in a way that we do not currently, (see @scolapasta's suggestion above), and in a way that is separate from other notifications.

• add the ability to include a text link in a banner, similar to how we manage Dataverse descriptions

• the message remains until the user has dismissed it

• dismissing is tracked for each banner

Proposed Table Design:

A Notification Banner table which would include a text field for header and message analogous to the settings table entries of :StatusMessageHeader and :StatusMessageText, and a nullable time stamp after which the message would not display. (if null, the message would have to be dismissed by each user.)

A join table for NotificationBanner/AuthenticatedUser, which would include ids for each and a time stamp for when the user has dismissed the notification.

Something like this:

Immediate Questions:
Are we thinking of continuing to use :StatusMessageHeader and :StatusMessageText for short term notifications?
Would we delete old notification banner records along with records from the join table?

In the case of a user that is not logged in, I'm assuming that we would post any notification that has not expired. Once they log in we can check if they have dismissed it.

Thanks @scolapasta and @sekmiller for discussing just now:

• Expiration date is out of scope
• Instead of header we can just define the whole thing in HTML using bolding
• We should handle multiple languages, look to how we handled it in Terms of Use internationalization (Internationalization - Terms of Use #5303)
• Add a boolean for dismissible for user vs persists until removed by admin
• Consider renaming the table from UserNotifications (something banner-related)

Updated table design based on recent discussion:

if the boolean dismissibleByUser is false the banner will be shown until the record in the table is deleted. It may be dismissed in a session. If it is true then it will only be shown to logged in users (and only if the dismissalTime in the join table for that user is null)

Reviewed a WIP demo. To dos include:

• testing the message with a text link
• enabling the message to be deleted (need the message ID)

We discussed that if the user changes the language after dismissing the alert, the alert will not be displayed a second time, because changing the language does not change the session (or the user).