In this article, we show you a typical example that can be encountered more often that you think. The subject that we have chosen, concerns a message module for an Intranet shop platform.
The central management sends newsletters to all shops in order to inform them about internal procedures, holidays, job opportunities, contact updates, ...
Issue 1 : Display count unread messages
Issue 2 : Highlight unread items in the list
A shop manager or an employee is linked to a shop except for the other permissions such as admin, sales team,...
During the meeting scope, the customer explained that the first user of the shop who will click on an unread newsletter will set it to "read".
So, the dev team built this following database model :
With this schema, we have 2 problems :
When the employee A of the shop 001 reads the newsletter, the status of that newsletter is set to "read". Right?
And now? What happens if the employee B,C,D,... of the same shop is connected to the inbox?
The employee B,C,D of the shop 001 will have a read status instead of a unread status for the newsletter and the unread count will be 0. This simple detail can mislead the user into thinking that he has already read the message when he has not and therefore, miss important information.
Reminder : only employees and shop managers are linked to a shop. So how others users can see highlighted items or right count if the message status is linked to a shop ?
With this simple change, you solve the 2 constraints at the same time.
Any user profiles can see read or unread status messages and the right unread count to the top.
When the customer asks something, we have to think outside the box. In this example, the dev team followed the requirements letters by letters without anticipating impacts in the future.
We could also improve this analysis by adding for example, a type of messages (newsletters, individual messages,...), defining groups of users by shop,...