WOCAT » QCAT

h1. Wiki

h2. Technologies and Approaches

!schema_core_links.PNG!

A decision was taken to keep Technologies (QT) and Approaches (QM) separate with the possibility to create links between them. This prevents data redundancy when for example several Technologies share the same Approach. This linkage was already available in the old WOCAT database, but links need to be cleaned up.

Both Approaches and Technologies have a core part (QT core, respectively QA core) containing a basic set of questions. An additional part (QT plus / QA plus) can be used to display the full set of questions. Further links to other modules will be possible.

h3. Sample user story

* User Alice wants to add a new Technology, so she logs in to QCAT

* She enters the form of the Questionnaire on Technologies and sees the Core questions by default. 

* She also has the option to fill out the Plus questionnaire where she sees all the questions. 

* She fills out every section with the values automatically being filled in the output format of the Questionnaire. 

* At the end of the form, she has the possibility to link other Questionnaires. 

    * She can add an existing Approach by searching and selecting it. 

    * [It is possible that for the time being, only existing questionnaires can be linked so if she wants to link an Approach which does not exist yet, she would have to go to the Approach form and create an Approach. After that, she can go back to the Technology form and link it.]

h2. Review workflow

The workflow when submitting a new Questionnaire or editing an existing one is as follows:

* A logged in User A can create a new Questionnaire or start editing an existing one.

  * When he does *[save]* his changes, it creates a new version (with the existing code if available) with status *@draft@*.

  * The user can add other users (editors) which can make edits to the draft. While a user is working on the draft, the version is locked for other editors to prevent conflicting edits.

* The original user (User A) can *[submit]* the version which receives status *@pending@*.

  * No more edits can be made to the version.

  * The moderators are notified that there is a new pending version.

  * A moderator reviews the version and decides what to do next:

  * Review decision *[publish]*: The changes are ok, the version receives status *@approved@*.

    * The approved version is inserted in Elasticsearch (replacing older ones).

    * Any old version receives status *@inactive@*.

    * All editors are notified.

  * Review decision *[reject]*: The changes are very wrong, the version receives status *@rejected@*.

    * All editors are notified.

  * Review decision *[revise]*: Corrections need to be made, the status of the version is set back to *@draft@*.

    * All editors are notified.

    * The users can make changes to the questionnaire again (review procedure starts again)

*Missing*: "revise" decisions need to be logged somehow. It should be possible to pass messages from user to user (eg. users submitting comment for the reviewer or reviewer submitting comment for the editors when "revise").

h2. Concept

   * [[Technologies, Approaches and Modules]]

h2. Versioning and Review

 * [[Review process]]

 * Versioning in the database see: document#2

h2. Elasticsearch

* [[Elasticsearch and QCAT]]