nexedi / slapos.core

@tomo @rafael

marked as a Work In Progress

added 1 commit

• 49b71fba - [slapos_jio] Display Unread Messages on SlapOS Home page

Compare with previous version

added 1 commit

• 347ede28 - [slapos_jio] add menu to view all unread messages

Compare with previous version

unmarked as a Work In Progress

no, please keep 1 .html per portal type and reuse same .js

[I edited the message after re-read the MR]

I think this implementation has some major problems in my understanding.

First, from UI point of view, it workarround to redirect when the user view a message, instead place the appropriate URL on the Listbox. This seems wrong, it should be possible to modify the link. I think I did it once (I just don't remember which form).

Second is a major problem on design, the read/unread is a bit wrong here. If anything implements a jio_get on the event the message is marked read... this is wrong. You cannot edit something in a get (this should be a code crime), even so, you have no guarantee that who did the get was the UI you wanted. So this is wrong, in any case, it should be changed to make at least a putAttachement to change it's workflow.

(I know that I use getAttachement to edit in one or two cases but it due a lack of a certain API on Jio, which will be replaced get an update)

In case you want to mark something read, as I think you should use portal_acknowledgements on a "unread" state and not get directly Events, maybe it will be require to polish the tool, but at least seems a more appropriated design (I'm suggesting it during the latest weeks).

You can only deliver "sent" messages, this is probably ok currently, but if the message was sent to 2 users or to all members of an organisation/project? How to handle?

For example, Once we change to list all hosting subscriptions or computers attached to a project to all members of a project all the tickets will be shared, so this "deliver" will mark "read" the first one that open the ticket. The second that arrives wont get it listed.

So, if we change security as planned, this entire implementation will be dropped and require be reimplemented.

Please, if you intent to mark it read w/o use Acknoledgement API, so please justify very clearly the design decision and how "shared" tickets will be handled, because I'm talking about to use it during 3 weeks and I see no reason to do it diferently.

Please see the basic API, seems what you intent: https://lab.nexedi.com/nexedi/erp5/blob/master/product/ERP5/Tool/AcknowledgementTool.py

Acknowledgement can be used in situations where you want to inform the user that the whatever a hosting subscription started or stopped, or Connection parameters are available (no idea, but quick information).

In case of Acknowledgement, btw, the "redirect" implementation seems somehow more reasonable, if it do a putAttachement before redirect maybe.

Side Note: I'm not sure how we can consider an send email "Read" or not.... I think Mail Messages shouldn't be included there, only Web Messages, as Mail are managed on the email readers.

Side Note: Another weird thing is, if the message has less them 80 chars, the entire message will be displayed on the listbox, so the user won't click on it... but he actually read it, it might force the use access it to remove from the list.

@nexedi Maybe, this use case is maybe present on another project, so I ask widely... Does someone uses portal_acknowledgements or Acknowledgement messages to mark things read (or similar), which can share your ideas or the general design?

portal_acknowledgements and Acknowledgements are used since 9 years on a German project. We use following scenario:

• a Site Message (kind of email, with attachements) is created from time to time (about once every month to share release notes) with informations that needs to be shared to many users. The site message has in the field "Recipients" all persons that should read this information
• by default, every user has in it's preference, in tab "User Interface" the checkbox "Acknowledgeable Messages" enabled
• every time an user is using ERP5, acknowledgement tool is used to check if user has unread message (in reality there is cache to avoid cosuming too much resources). If yes, in a very invasive way, ERP5 display the message. What is displayed is a temp acknowledgment which is a kind of proxy to the original document (site message), because the user might not have the right to see the original message. Every displayed message has a button "mark read" or something similar.
• when user click on "mark read" then an Acknowledment document is created in event module. It is linked to the original document, and it is kind of proxy to allow reading the original document at any time.
• then when ERP5 look for unread document, since the site message has been acknowledge, it is not displayed any more to the user

@seb Thanks it is very clear. I thought we would generate the acknowledgement up front, but it is true that TempDocument seems quite clever on this case.

Let me explain what I want in the end and if it is OK with you @rafael :

• for tickets and upgrade decision: I want to use worklist
• for all other notifications ("your instance is ready", "slapos master will go down for maintenance", "COMP-XXXX will reboot so your instance YYYYY will be down for a few minutes", ...) I want to use Acknowledgements.

In my idea, the worklist for a given user will list all open tickets waiting for customer and all pending upgrade decisions. For the tickets, we will need to add a new state in the workflow ("waiting for customer"), for upgrade decision nothing todo, all open upgrade decision will be in the worklist. So the goal will be to have the worklist empty for all the customers (a ticket must be closed (-> state closed) or answered (-> state waiting for vifib) and an upgrade decision must be accepted or rejected to be removed from the worklist). In the menu, we will have a new entry "worklist (X)" with X the number of item in the worklist so that the user always see if there is something in the worklist.

As a first step before implementing worklist as described above, I wanted Alain to do a "chip replacement" : all the unread WebMessages from Support Requests and Upgrade Decision would be listed in the menu. As this is a temporary solution, we can accept to have a get modifying the state of the object. For information, in "a customer project" they are doing just the same thing (a hidden field in the ERP5 view form will call a script to mark this object as read so it is done with a "get") that's why I supposed it was acceptable.

So do you agree with the worklist goal ? Is it achievable soon enough to drop this MR totally and work immediately on the worklist solution ? If not, do you accept this MR temporarily ?

Even if you assume this design (which is ok), the implementation itself has way too many problems like I said up there, so we are not in hte state to "accept temporarily".

By the way:

• for tickets and upgrade decision: I want to use worklist

• for all other notifications ("your instance is ready", "slapos master will go down for maintenance", "COMP-XXXX will reboot so your instance YYYYY will be down for a few minutes", ...) I want to use Acknowledgements.

... in my understand, this is good, exactly how erp5_crm and acknowledgment tool are supposed to be used.

add a new state in the workflow ("waiting for customer")

Without thinking much, I want to share an idea that maybe this is not needed. "Open" state means "waiting for someone". "someone" is whoever has Assignee role and this can role be dynamically calculated by role definitions on the ticket. Maybe this can be achieved without changing the workflow, by implementing the logic in role definitions, for example "if latest message source was from Vifib, then assignee is the customer". I'm not sure it will be easier to configure using this way in the end. In some customer projects, we use this approach to configure the security of internal invoices, so that everytime one of the party make a change to the invoice, the other one has to validate.

Get assignee from the last message... clever. The problem is when the message is "Oh, I'm checking/Working on it", kind of messages. But I think the logic can be adjusted (by using certain event resource maybe which do not transfer assignee role).

I also though to use Event, w/o change Roles on Ticket in my case. More or less define "Message to respond" or even use "Acknowledgement (with a resource)" to assign blame, like "Todo" in gitlab, where Read is not enough, you have to mark as done.