Workflow and Role Management
Roles will be represented as as workflows customized and assigned to project members. Each project member will have one or more roles and each role will have a configured workflow and configured set of tools.
When a workbench user creates a project (assuming they have the authority), that user is assigned the Manager Role for the project which has a complete workflow (or menu) of all the tools available for that project.
Once this role is assigned the manager can configure the project:
- Select and configure tools
- Select Breeding methods
- Select Locations
The manager can then add other roles for himself (eg MARS if he is the breeder and doing a MARS project), and configure those roles by adding or deleting steps and tools and adding methods and locations or configuring tools. However most configurations would be simply inherited from the project manager role.
Next, the Manager can add project members from the list of Workbench Users (adding Workbench Users first if necessary), and he or they can add and configure roles for those members.
When a user logs on to the workbench, the list of projects for which he has at least one role will be shown. When one of the projects is highlighted, the roles will be shown in the details panel, and clicking on a role will launch the workflow for that role.
Some implications of these specifications are that Roles (personalized workflows and configured tools must be managed at the project member level in the Workbench Database.
Each tool will have configuration settings at the Role level. These consist of Key-Value pairs which can be read by the tool on start up from the workbench. The tools may read these settings from the Workbench database, or from an external file. The Workbench may prepare this file (if the format is known), or the setting may simply be a pointer to the a file which must be prepared by the tool supplier. This allows third party tools to be easily incorporated into the Workbench for specific users or projects. For example some legacy ICIS tools could be included by simply having a setting INI File=Path. The manager of those tools is responsible for providing the ini file for each project.
Project data administration
The Workbench needs an administration section where project users can request a backup of the local project IBDB, and a restore if they have the right privileges. Presumably this would use the standard MySQL backup facilities and result in a zipped backup file which could be stored safely. A common use of this feature would be for new users to re-set their database if they make data management mistakes, and for training we use it to set the local environment to a standard state for each lesson.
A possible upload and update procedure would be for a project administrator to select upload from the administration section. This would create a backup of the local IBDB and block write access to the local IBDB until after the update. A copy of the backup would be sent to the central crop administrator who would upload the local data to the central (including project users for first time uploads), clean out the local database and create a new central installer and a local database installer for the project. The Workbench administrator would download and install the new central, and the project administrator would download and install the new local. (The old local will not work with the new central because the installation record is checked at log on by the middleware.) The local installer need only be a backup of the cleaned local so that it could be updated via the administration section of the Workbench in order to verify the project administrator before replacing the local database.