Overview

The Must Reads feature is a way for managers of an organization to assign items that are "Must Read" to subordinates. This can also be used in other contexts, for example, the central office manager might want to specify items as Must Read for individual managers of each and every district office.

While it is tricky to ensure that someone in fact reads something (we'd have to add some tests)

making it a must read, 1) it tells people that this is important and to pay attention, and 2) if someone goes against the new policy, they can't make the excuse of 'Oh, I didn't get the memo'.

This is very useful for some types of organizations.

Requirements

Permissions

We need a perm to determine which users has permission to assign “Must Reads” to other groups of users.

An easy way to add object to Must Read list

Any object in Tiki must be addable to the Must Read list. There should be an easy way to do this for any item, e.g. the item being viewed. The person doing the "adding" selects from a list of Tiki Groups to add the item to the Must Read list. The list of groups selectable should be limited to the groups (or the "included groups") that the user is in. In addition, certain groups such as "Admins" "Registered" etc should be able to be blacklisted from being shown on these lists.

In addition, there should be a user selector to select one or more individual users.

Once an item has "Must-reads" assigned, the button/UI for assigning further Must-Reads will show what has already be assigned (to avoid users reassigning again and again)

Link in to notification stream

Upon receiving a "Must Read" directive, a user gets a high-priority notification added to his notification stream, which should generate an email notification.

A dashboard of the incoming and outgoing Must Reads

Each user must be able to see a dashboard of his "Must Read" list, i.e. what others (or even himself) have identified as "Must Read" for himself.

The dashboard indicates to the user how many unread items, how many items they have to circulate, and how many completed items he has. If the user has permission to send Must Reads, he can also see how many “outgoing” Must Reads that he has sent.

It also lists each item in a table (separate tables for “incoming” and “outgoing” must reads), and the status. The table is sortable by the various columns:

• Title
• Brief Description
• Assigned (and Circulated if applicable) By
• Release Date
• Action Required (i.e. Read or Circulate)
• Whether Completed or not

When each of these listed items are clicked on, more details for that item is shown below:

• how many (and which) users sent to, how many (and which)opened
• how many (and which) of these users have logged in
• how many (and which) unopened
• how many users, and for each of these users if they still need to "Comment", "Reply Privately" or “Circulate” and if they have done so or not.

There will be link to the item.

Reminder sending

There will also be a button for the person who sent the Must Read to trigger a reminder notification to be sent for all “uncompleted” recipients of the Must Read here.

A way to respond to the person sending the "Must Read".

There should be a easy way to respond to the person sending the "Must Read". The typical use case is that the manager asks everyone to not only read it but also to "do something, e.g. give me your feedback, or etc... One simple way to implement this is to use the Tiki Comments feature and so the response specifically required is to comment on the item. But there is another use case where the manager does not want everyone to see each other's comments, then a private message may be better method for this (this can be through the wikiplugin_mail). Perhaps the manager should be given the option to request either of these forms of responses when setting up the "Must Read".

In every case, the UI to do the action should be on the page where the item is being viewed itself (there would need to be some kind of button, maybe the same Must Reads button that is used to assign Must Reads), whether it is to :

• Acknowledge as read
• Circulate
• Comment
• Respond privately

In the case of “Circulate”, he can click on “Circulate” and choose Groups and users to circulate to, just like a user who is creating a new Must Read. Once the circulation is done, the Must Read (for the viewing user) becomes complete.

In the case of “Comment”, the user is directed to comment using the standard commenting capabilities for the item. Once a comment is posted, the Must Read (for the viewing user) becomes complete.

In the case of “Respond Privately” through email, a box is provided for the contents of the email to be entered by the user (the system automatically determines the recipient email, i.e. the email of the person that created the Must Read). Once the user clicks send, the email is sent, and the Must Read (for the viewing user) becomes complete.

A way to circulate to others

Many times, the director of an organization may not know who are all the groups of people who need to read an article. So, he simply sends the Must Read to e.g. the "Managers" group. It is then up to the "Managers" group to Circulate the Must Read to others under their purview. It is therefore necessary for a user to be able to set as an action "to Circulate" for a Must Read that is created. Once the recipients have further sent on the Must Read to other groups, then the "Circulate" action is tracked as done, and is shown as part of the stats below in the dashboard of Must Reads sent.