Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
req:ticketing2010 [2010/01/17 04:04] gavintreadgold |
req:ticketing2010 [2010/12/18 17:35] (current) |
||
|---|---|---|---|
| Line 30: | Line 30: | ||
| * AJAX update to highlight message marked as urgent (e.g. highlight background light red or similar) | * AJAX update to highlight message marked as urgent (e.g. highlight background light red or similar) | ||
| * When creating a message it would be useful to allow uploading a document to a document library module (not yet developed) and then linking that back to the original message it was sourced from. This would allow two-way linking e.g. from message to document, or document to message | * When creating a message it would be useful to allow uploading a document to a document library module (not yet developed) and then linking that back to the original message it was sourced from. This would allow two-way linking e.g. from message to document, or document to message | ||
| + | |||
| + | |||
| + | ===== Action Tracking module ===== | ||
| + | Incoming messages need to be reviewed by a subset of users to identify if actions are required to be undertaken. A given message may result in 1 or more actions being identified, and these need to be recorded, and allow the assignment of actions to users, as well as expected completion times. The users should be able to mark actions assigned to them as underway, completed etc. We also need to be able to track what sort of Sahana system rights may be required, e.g. admin, data entry etc is required to undertake the task. Again, Actions and Incoming Messages should have a two-way linkage, so that actions associated with an incoming messages are shown, and likewise it is possible to view the source message that generated an action. | ||
| ===== Document Library module ===== | ===== Document Library module ===== | ||
| Line 45: | Line 49: | ||
| Options: | Options: | ||
| * Included fulltext searching of uploaded documents | * Included fulltext searching of uploaded documents | ||
| - | |||
| - | ===== Action Tracking module ===== | ||
| - | Incoming messages need to be reviewed by a subset of users to identify if actions are required to be undertaken. A given message may result in 1 or more actions being identified, and these need to be recorded, and allow the assignment of actions to users, as well as expected completion times. The users should be able to mark actions assigned to them as underway, completed etc. We also need to be able to track what sort of Sahana system rights may be required, e.g. admin, data entry etc is required to undertake the task. Again, Actions and Incoming Messages should have a two-way linkage, so that actions associated with an incoming messages are shown, and likewise it is possible to view the source message that generated an action. | ||
| ===== Additional Notes ===== | ===== Additional Notes ===== | ||
| * Comments - it would be good to allow users to comment, a la blog style, against an Incoming Message, Document or Action | * Comments - it would be good to allow users to comment, a la blog style, against an Incoming Message, Document or Action | ||
| * Situation Awareness - an Incoming Message may also generate 1 or more situation awareness points, and these should also be linked in a two-way manner as per actions and documents, so that Situation Awareness points can link back to original source message and vv. | * Situation Awareness - an Incoming Message may also generate 1 or more situation awareness points, and these should also be linked in a two-way manner as per actions and documents, so that Situation Awareness points can link back to original source message and vv. | ||
| + | * Personnel Management - any assignment of actions needs to link to the Personnel Management system | ||
| + | * Organisation Registry - some actions may be assigned to orgs from the OR, and then the manager of the Organisation that has an assigned action may decide which user within their org will be responsible for the action | ||
