| | 40 | * When a message is picked up by the handler, it decides whether it's an XForm or not. |
| | 41 | * If it is, then it is routed direct to the relevant resource. |
| | 42 | * If not then it is added to the Master Message Log ({{{msg_log}}}) |
| | 43 | * When new messages arrive in the Master Message Log, then the Parser looks for keywords & tries to Route automatically - either to a resource or to a {{{pe_pentity}}} (NB 'routing' to a resource is actually just 'tagging'). |
| | 44 | * Users can view the Master Message Log via the 'Ticketing Module' UI & do manual Routing - either to a resource or a {{{pe_pentity}}}. |
| | 45 | * Users can Subscribe to Resources in order to receive copies of all messages which are routed to a resource. |
| | 46 | * When a user visits a Resource via it's Web UI, then the [wiki:RESTController] scans the {{{msg_log}}} & provides access to associated messages in the views (display/update views have a list of associated messages in a table below the main record. list views have an extra column showing the number of messages tagged to this resource & number unread by this user ({{{unread(read)}}}) which is hyperlinked to a view which displays these records. |
| | 47 | * XML exports (such as RSS feeds) include tagged messages as linked resources. |
| 41 | | |
| | 49 | ==== How do we achieve this? ==== |
| | 50 | * Table {{{pe_subscription}}} is used to maintain subscriptions for a {{{pe_pentity}}}. |
| | 51 | * Fields: ''tbc'' |
| | 52 | * Table {{{msg_delivery_status}}} is used to store delivery statuses. |
| | 53 | * Fields: message_id, pe_contact_id, status |
| | 54 | * Table {{{msg_read_status}}} is used to show that a message has been read by a user. |
| | 55 | * Fields: message_id, auth_user_id ('read' is assumed) |
| | 56 | * Q: Do we mark as read if pe_contact_id status suggests person has received message? |
| | 57 | * Good to have UI to 'Mark Unread' |
