Forcabily acquiring a lock doesn't sent emails to the backend users

Hi all


Normally when system administrator forcibly tries and acquires a lock of a standard page asset of existing backend users. Should it not send an email directly to the backend user? Currently it is not doing it for there own individual inboxes. :blink:



All other messages in regards to the workflow are working fine for the individual’s inbox :wink:



These messages 'forcibly acquiring a lock' are only appearing inside the SQ_INTERNAL_MSG table of the database for individual backend users.







For example john is a backend user, inside his inbox it only shows as only 1 message, but inside the SQ_INTERNAL_MSG table, for that person it shows as 9, therefore 8 messages are not showing up because all are forcibly acquired. This is quite misleading



cheers :lol:

I'm not exactly sure what the problem is here?


Basically the problem is??

Why is there a variation of the number of messages being displayed in John inbox on the admin interface and in the SQ_INTERNAL_MSG, when you run a SQL on John it show 9 messages inside the Database, but only 1 in the admin interface of the system?

The other 8 messages inside the Database are forcibily aquire lock messages.

cheers :lol:

Maybe he deleted those messages and they're in his Trash folder? They'll still be in the sq_internal_msg table, but will not show up in the Inbox.

There is no logic behind this as far as i could understand.

If a backend user deletes there own internal messages, how can it be in his or her trash folder.


Why should it be in the sq_internal_msg table, if a user decided to delete it from his or her own inbox from the admin interface. This logic is not correct at all. ;)

The sq_internal_msg stores all internal messages. Every user has both an Inbox and a Trash folder. If you delete a message from your Inbox we change a flag in sq_internal_msg so it no longer appears. It doesn't mean the message has been removed though. You need to delete messages from the Trash for them to be removed from the sq_internal_msg table.

This logic is correct and it allows users to restore messages they may have deleted too quickly, just like Trash folders work in email.