Together with other members of Team Mind The Parrot, we’ve started work on our new epic - Dashboard Administrative Messages. During my work on OLMIS-6321, I designed a database model and RAML for administrative messages. I’ve pushed the suggested solution to the dev branch. In my solution, AdministrativeMessage object has three required fields: id, message, and expiry date, and 2 additional fields: title and created date. The expiry date column is indexed. Available actions are: getting all messages, searching by expiry date (messages expiring before/after the provided date or in date range), getting by id, creating and deleting. The administrator can remove the old message or leave it in the system as expired. On UI, we can display all messages and highlight somehow that some of them are expired.
What are your thoughts? I would appreciate your feedback very much.
Thanks for this Klaudia,
some small comments.
I find the choice of required fields weird. Why is the expiration date required, but the created date isn’t? What are the cases where we wouldn’t want to have the created date set? Also, have you considered support for messages that do not expire? It seems that with expiration date being required, we wouldn’t be able to achieve this.
For the fields, I think two are missing: author and active. Active could be an additional switch that easily allows to turn messages on and off as needed.
As for the APIs, the crucial thing is that we can easily retrieve “active” messages. This should be available to all logged users and return enabled non-expired messages. Other than that, we just need the CRUD for admin to manage them. Is it currently possible with your design? How would the call look like?
You are right, I’ll mark created date as required instead of expiry date. I thought that the administrator will be the only author of administrative messages, that’s why I didn’t add this field. I can add it if there is a need. In case of the active flag - isn’t it a duplication of the info provided by expiry date? Your suggestion is to remove the second one or use both, active and expiry date? In the first solution, the administrator will have to manually mark the message as inactive. Otherwise, should we automatically mark expired messages as inactive?
API enables retrieving non-expired messages - you can search for messages that expire after today’s date but with the active flag, it probably would be more clear. All CRUD operations are available, here you can find the details: https://github.com/OpenLMIS/openlmis-referencedata/blob/1cfa0fe32320efc1df7d08635022417fa986a02f/src/main/resources/api-definition.yaml#L3403.
Thanks a lot for your feedback,
I think we should be basing this on the rights. Every user that has got a role with this right assigned would then be able to manage administrative messages.
I was suggesting we would use both active and expiration date fields. A message would need to be both active and non-expired in order to be displayed. If there’s no expiration date, only the flag would control whether the message is displayed or not. This would also allow users to prepare messages in advance. They could mark it as inactive, and then enable it once the message is meant to be displayed. In the future (or now?) we can also think of having the optional start date parameter, that would allow to plan the messages that are meant to be displayed in the future.
Thanks for this work!
Thanks for the clarification
I’ve updated the design and pushed changes to the dev branch. Here is the commit. Does it look better now?
the changes look good to me. I’d also add an index on the authorId foreign key. Other than that I don’t have any more comments.
Great! The last change is already pushed to the dev branch.
Thanks for the suggestion,
Does anyone have any other questions or comments? If not, I’ll create a ticket for implementation.
I had a question. Does this mean that if there is an administrative message, every time an end user logs in, they will see the message, and there is no way to “dismiss” the message?
@Chongsun_Ahn, yes - to keep things simple for the initial version there’s no way for the user to dismiss the messages or interact with them in any other way. This, as well as many other expansions, have been suggested on the Product Committee call, but we agreed to go with a simple version for the start, and then prioritize based on needs/received feedback. I think though that we may at least create tickets in our backlog for all of those possible additions to admin messages.