Student projects/Workflow Support

Note: This page outlines ideas for the "workflow support for database records" project.

Original Idea Summary

The aim of this project is to provide workflow support for database records. In particular, we provide with the ability to control the state of a record, permissions for different user groups at different state levels, and an alert system to send out notification to users whenever a record changes states i.e., an action is performed.

With this project, I hope to lay foundation for a full-fledged workflow control module for Moodle, that will go a long way to manage content easily in future.

Student: Akshit Sharma

Mentors: David Mudrak

(These are not the final students/mentors who will work on this project)

Project Proposal

Terminologies used

• Workflow is a chain of "actions" that occours on a "content type" to achieve an objective by transiting over "states".
• There is a permission hierarchy for the content type (for which workflow is applied). For e.g., "Edit" > "View" are two permissions in decreasing hierarchy. "Edit" permission implies "View" permission.
• Each type of user can have different permissions on the content-type in any state.

Goals to be achieved

• The goal of this project is to provide workflow support for database records.
• In particular, we provide with the ability to control the state of a database record, and permissions for different user groups at different state levels.
• To send out notification to users (by emails, for example) whenever a database record changes states i.e., an action is performed.

The Approach

• We build a default workflow for the system.
• Predefined features of the default workflow are described below :-

1. This workflow will have some predefined states. For e.g. :-
   1. Pending,
   2. Private,
   3. Published,
   4. Visible
2. This default workflow has predefined actions (or transitions). These actions take the database record from one state to another. These actions can be :-
   1. Submit,
   2. Hide,
   3. Show,
   4. Publish,
   5. Retract (Undo Publish and/or Submit)
3. These predefined actions take the database record from one state to another as defined here:-
   1. Submit: Visible -> Pending
   2. Publish: Pending -> Published
   3. Hide: Visible/Pending -> Private
   4. Show: Private -> Visible
   5. Retract: Pending/Published -> Visible
4. Each state has predefined permissions for each type of users. For e.g. there can be a user who created the database record ("Creator") and a normal user ("Viewer"), for the default workflow :-
   1. In Pending state, the "Creator" can "Edit" the document, but the "User" can only "View" the document.
   2. In Private state, the "Creator" can only "View" the document, but the "User" has no permissions on the document.
   3. In "Published" and "Visible" states, both the "Admin" and "User" have only the "View" permission over the document.
   4. In effect, the creator of the database record can always view the record, but a normal user can view it only when the record is not in the Private state.
5. A better understanding of the "default" workflow can be had from the image on the right where the states, actions, transitions and permissions are clearly shown.
6. NOTE - These pre-defined values (states, transitions, permissions) are just a proposal. They might change while actually implementing the default workflow depending on more discussions with the mentor and the community.

• Allow the user to modify the workflow.
• The modification in workflow can be done only by the creator of the record.

• Allow him to add more states to default workflow
• Allow him to define more actions.
• For each state/action he has added, he will have to define the new transition rules.
• Allow him to explicitly take/grant permissions to users.

• Let the user save the modified workflow.
• While assigning workflow to the record, the user will be able to choose from the default workflow as well as all the other workflows he has saved.

Implementation Proposal

I have seen and studied Plone Workflow tool (DCWorkflow - By Zope Corp). I propose this implementation scheme on the same lines as DCWorkflow has. The implementation is broken in two broad phases.

Phase 1 - Create, Store, Modify workflows

1. Use workflow definition filetype (.wfd) to store workflow.
2. Create the default workflow (as discussed above) in the workflow definition (.wfd) format and save it in appropriate directory.
3. Create a block - workflow_manager with following functionality. In the block, display all the workflows that have been saved (initially it will display only the default workflow).
   1. As a test, we can create a couple of more workflows and save them to see if the block is actually displaying all of the saved workflows or not.
   2. The block will look something like this.
4. Within the block, provide the user to choose an existing workflow, and modify it (as discussed above).
   1. Provide a GUI to add states: something like this. The new state added is called "Publish to Group 1".
   2. Provide a GUI to add transitions: something like this.
   3. Provide a GUI to define transition rules: something like this. This shows all possible transitions that can take place.
   4. Provide a GUI to grant/take permissions: something like this.
   5. After modifying the workflow to user's needs, we let the user save the modified workflow.
   6. The block will now show the newly saved workflow also.

Phase 2 - Set workflows to database records

1. All the information till now (i.e. definition of workflow) was stored as .wfd files, and there was no interaction with DB till now.
2. Create database tables for the block this can be done using the following files.
   1. upgrade.php
   2. install.xml.
3. The database tables will store the following information :-
   1. Which database record has been set with which workflow.
   2. What is the current state of the database record.
4. Using the block, let the user be given the option to apply any of the workflows to a database record: something like this. On applying a workflow to a record, the information is updated in the database created in step 2 and 3.
5. Whenever any of the "actions" is taken, the state of the record in the database is updated according to the rules specified in the workflow corresponding to that record (remeber: in the DB we store record, workflow, current_state).
6. Whenever any of the "actions" is taken, an email is sent to the "creator" of the record as well as to all the users who have the ability to "view" the record.

Deliverables and Timeline

The work will be broken up according to the three trimesters.

First Trimester

(20 April - 30 April)

• Discuss idea within the community and ask for advice/criticism
• Update the project outline with all inputs (more ideas or suggestions or criticism) received from the community.
• Deliverable - Deliver a final plan of implementation with technical details of implementation (wherever missing)

(1 May - 12 May)

• Discuss the structure of default workflow within the community and decide on the best default workflow.
• Deliverable - Description of default workflow (graphic or descriptive)

(13 May - 22 May)

• Design the .wfd file for the default workflow.
• Deliverable - Deliver the .wfd file for the default workflow

Second Trimester

(23 May - 30 May)

• Create a block that displays the currently saved workflows (initially "default" workflow) from a particular directory.
• Create a couple of more workflows and save them to see if the block is actually displaying all of the saved workflows or not.
• Deliverable - A block that achieves the above tasks.

(31 May - 15 July)

• Update the block to allow users to add states, transitions, transition rules, and permissions.
• Allow user to save the new workflow (in appropriate directory).
• Deliverable - A block that achieves the above mentioned tasks

Third Trimester

(16 July - 18 July)

• Create update.php and install.xml to create databases
• Deliverable - A block with the above mentioned two files that automatically creates databases during installation.

(19 July - 5 August)

• Allow the user the option to apply any of the workflows to a database record and update the database with this information.
• Whenever any of the "actions" is taken, the state of the record in the database should be updated appropriately.
• Deliverable - A block that achieves the above mentioned tasks

(6 August - 8 August)

• Whenever any of the "actions" is taken, an email should be sent to the "creator" as well as all the users who have the "view" permission for that record.
• Deliverable - Updated code of the block that achieves the above functionality.

(9 August - 10 August)

• Documentation and Community reviews.

See also

• Projects_for_new_developers
• Moodle Workflow support forum discussion
• Tracker issue MDL-18572