Users should have access to receive messages that they see upon logging into the system.
Notifications are divided as follows:
1. Notifications displayed before the client logs into the system
Appear between the header "Client Portal" and the email input field.
Must be visually highlighted — for example, with a background (red or yellow) or in another way — design at your discretion.
Specify the date and time during which the notification is displayed.
The start time of the display is set by default, but may not match the time the notification was created.
The end date and time by default is the next day, 23:59.
If there are multiple notifications, they are combined into one block, where there can be up to 4-5 sentences; each notification has the start date and time of its action indicated in a smaller font.
Sorting — by start date (in ascending order).
2. Notifications displayed after the client logs into the system (before starting work)
Appear on the main page (Panel / "Overview") — between the header "Overview" and the action list.
Several behavior options are possible:
Displayed for a specified period (start/end date and time);
Or displayed until the user clicks the "I confirm reading" button — after that, the notification is no longer shown to this user. Until the button is clicked, navigation to other sections of the portal is prohibited. In this case, the end date does not matter.
Or displayed with a confirmation requirement, but before the end date are shown every time upon login, even if the user has already clicked "I confirm reading". This is suitable, for example, for reminders about client debt.
If there are multiple notifications, they are also combined into one block.
The "I confirm reading" button appears once for the entire group of active notifications and only if among them there is at least one that requires confirmation.Notifications can be:
for all users,
for users of specific clients (multiple client selection),
only for specific roles (in this case, the client does not matter — the notification is shown to everyone with that role).
3. General requirements
All notifications allow text formatting and the use of external/internal links.
All notifications and confirmations must be displayed without pop-up windows.
4. Notification administration
Available in a separate section, currently only for the role of "debug master" (in the future, a separate role may be created).
Capabilities: creation, searching, filtering, editing, and deleting notifications, similar to the already implemented filtering and multi-selection of users, etc.
Notification fields:
Creation date and time
Creator (user)
Start display date and time (default = creation time)
End display date and time (can be null)
Mandatory confirmation of reading
Clients for whom it is shown (default — all)
Roles for which it is shown (default — all)
Message text — formatable, at least support for bold / italic / underline, ability to insert URL.
5. In the client section
Two links are added:
to create a notification, where the client is set by default;
to the list of notifications (including history) — those that were visible to this client (i.e., filter by clientId).
6. In the user section
It is possible to see which notifications were shown to this user for the first time, when and at what time — this data should match the user's login time.
Also, the list displays when the user clicked to confirm reading for notifications where this is required.
This is a general description.
We await questions and suggestions if you think something should be implemented differently.
Do you want me to also translate this text into English — so it can be used for technical specifications or internal documentation for the team?
Riga