| 5 | | * This feature must be enabled per annotation type. Existing annotation types will have it disabled by default |
| 6 | | * The current core API should be usable and behave more or less in a backwards compatible way for annotation types that have the option enabled. |
| 7 | | * Existing annotation values doesn't belong to any project and should be treated as '''default values''' if the project-specific setting is enabled for an annotation type. |
| 8 | | * When a users is working without an active project only the default values are visible/editable for annotations that are project-specific. |
| 9 | | * If an annotation has a default value but not any project-specific value when a project is active, the default value is visible and should be treated as if it was a project-specific value, except... |
| 10 | | * Default values are not editable (unless maybe via new API methods) when a project is active. Trying to change a default value results in a project-specific value being created instead. The default value is then no longer visible and should not match queries either. |
| 11 | | * Deleting a project-specific value makes the default value visible again. |
| 12 | | * Deleting a default value can only be done when no project is active (unless maybe via new API methods). |
| 13 | | * It is important that queries are working in a sensible way. When no project is active only default values can be searched. When a project is active both project-specific and default values are searched but default values that have been replaced with a project specific value should be ignored. |
| 14 | | * If a default value exists it is not possible to "unset" the annotation in a project, only to change it to a different value. |
| | 5 | 1. This feature must be enabled per annotation type. Existing annotation types will have it disabled by default. |
| | 6 | 2. The current core API should be usable and behave more or less in a backwards compatible way for annotation types that have the option enabled. |
| | 7 | 3. Existing annotation values doesn't belong to any project and should be treated as '''default values''' if the project-specific setting is enabled for an annotation type. |
| | 8 | 4. When a users is working without an active project only the default values are visible/editable for annotations that are project-specific. |
| | 9 | 5. If an annotation has a default value but not any project-specific value when a project is active, the default value is visible and should be treated as if it was a project-specific value, except... |
| | 10 | 6. Default values are not editable (unless maybe via new API methods) when a project is active. Trying to change a default value results in a project-specific value being created instead. The default value is then no longer visible and should not match queries either. |
| | 11 | 7. Deleting a project-specific value makes the default value visible again. |
| | 12 | 8. Deleting a default value can only be done when no project is active (unless maybe via new API methods). |
| | 13 | 9. It is important that queries are working in a sensible way. When no project is active only default values can be searched. When a project is active both project-specific and default values are searched but default values that have been replaced with a project specific value should be ignored. |
| | 14 | 10. If a default value exists it is not possible to "unset" the annotation in a project, only to change it to a different value. |
| | 15 | 11. Inherited annotations always belong to the same project as the parent annotation. No exceptions! This means that inheriting a default value always create a default inherited value even if a project is active. If a project-specific value is later created on the parent item it will not automatically be inherited. This may cause some confusion since the child item may display one value (the default) but navigating to the parent item will display the project-specific value. |
| | 16 | 12. Inheriting a project-specific value should override an earlier inherited default value. |
| | 24 | |
| | 25 | '''Some implementation details''' |
| | 26 | The approach taken to implement this feature is to add two columns to the `Annotations` table. |
| | 27 | |
| | 28 | * `project_id`: The id of the project the annotation belongs to or 0 for default values |
| | 29 | * `override_id`: The id of the annotation that contains the default value. 0 if this annotation is a default value or if there is no default value. |
| | 30 | |
| | 31 | When searching for annotations we can introduce filters in HQL/SQL statements: |
| | 32 | |
| | 33 | * `where ... project_id = <pid>` to find only project-specific annotations (or 0 to only find default values). |
| | 34 | * `where ... project_id = <pid> OR (project_id = 0 and id not in (select override_id from "Annotations" where ....))` to find project-specific annotations and default values that are not overidden. The subquery may have a different where clause depending on what we are looking for (for example, all annotation in an annotation set or all annotations of a specific annotation type). |
| | 35 | |
| | 36 | The `project_id` column is easy to handle since we always know if a project is active or not. The `override_id` column is more complicated since annotations may be created/updated/removed in any order. For example, creating a default value on an item that already has project-specific values must update the `override_id` column on all project-specific annotations to point to the newly created default value. |
| | 37 | |
| | 38 | Inherited annotations are even more complex since we must go up and check the parent annotations in order to know what to set for the `override_id` column. |
| | 39 | |
