Okay, just tested one thing. Dismissed the test banner, changed the start and end date, saved it and reloaded the page. No banner.
So once gone for a user, gone for good?
1 Like
Ah! Thatâs a very good point actually @Roi, and the short answer is yes.
Each banner is assigned an ID based on the index number, and the plugin-outlet name. Then, the ID of the closed banners are stored to browserâs local storage.
So, if a banner is closed, even if its configurationâs changes it will remain hidden.
I see that can be a problem; Iâll think of a better way to handle this. â Suggestions are welcome : )
1 Like
The versatile-banner uses a cookie name setting, which admins can change to make the banner visible again for users who dismissed it.
1 Like
Thanks for the pointer @Moin, renaming the cookie to invalidate the saved cookies looks like a very practical solution.
In Notification Banners the banners can be moved up and down to change the sorting order, or change the outlets. That can potentially keep a new banner hidden if there was a banner in the same place and dismissed previously.
Seems I need to change how the IDs defined, and then perhaps adapt the cookie method. 
Then cookies seem to be a better way than the ids, especially when the ids change when you change the sorting order. 
In my eyes it would be useful to generate a new (cookie) id every time the banner is changed.
About cycles: If it was Christmas already I would wish for a cycle which can be done in weekdays (one or more) and day of month (one or more). And maybe for both something like âevery xâ, so that I could choose e.g. âevery second Monday and Fridayâ or "every 1st and 16th of every third month).
Actually, I was able to solve this issue with a hybrid solution.
A new Banner config version setting which will apply to all banners; and new individual Banner ID values.
The real IDs for each banner are constructed using both of the values. This method should provide a better flexibility IMHO:
- An individual banner visibility can be reset by updating its Banner ID without affecting the other bannersâ visibility.
- If multiple bannersâ, or all bannersâ visibility needs to be reset, then the Banner config version can be updated.
I will deploy this change soon.
update: The v1.4.0 is now out.
Introduced a unique[1], required Banner ID field for each notification banner and updated related settings, migration logic, and tests to support this change. Additionally, added a Banner config version setting to help reset banner visibility for users when important changes occur. These improvements ensures that banner dismissal tracking to be more robust and future-proof.
The uniqueness is up to the user. Unfortunately the theme object settings donât allow requiring unique values. However, the tab label now uses the ID value to make them more visible. â©ïž
Wow great! Thank you! I will test and give you feedback. 
1 Like
Works as said! Great. Thank you again!
1 Like
I just noticed that when a banner should be displayed for all users and on top-notices it is also visible on the login and register screens. Which is not a big deal for desktop usage but itâs interfering with the usage of both screens on mobile devices. Is it possible to omit top-notices banners on these screens? If you ask me, I would not miss the banners also on the desktop version of the login/register screens. 
@Roi if you want to restrict the banners to logged-in users only, you can simply select all the TL groups in the audience.
Or perhaps you can use the available CSS selectors to hide the banner on login/register pages.
No, having the banner for not logged in users would be good.
Yes, I remembered that I also hid other stuff and now helped myself with CSS and display: none; for the login-page, signup-page and invite-page.