|Reported by:||nicklas||Owned by:||nicklas|
Description (last modified by nicklas)
This is a new feature that allows an annotation type to be configured as "project-specific". The main idea here is that annotations on items can be entered on a per-project basis. Switching to another project would make it possible to enter a different value that is only visible in that project.
At the core level this must be implemented in a way that doesn't upset existing client code (web client/extensions/plugins).
- This feature must be enabled per annotation type. Existing annotation types will have it disabled by default. Once this feature has been enabled it will not be possible to disabled it unless all existing project-specific annotations are first deleted.
- 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. Exception: The existing API is not enough to be able to create a project-specific annotation when a default value already exists.
- 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.
- When a users is working without an active project only the default values are visible/editable for annotations that are project-specific.
- 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.
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.
The core API needs to be updated for this behavior. The existing API will modified the default annotation values even when a project is active.
- Deleting a project-specific value makes the default value visible again.
- Deleting a default value can only be done when no project is active (unless maybe via new API methods).
- 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.
- If a default value exists it is not possible to "unset" the annotation in a project, only to change it to a different value.
- 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.
- Inheriting a project-specific value should override an earlier inherited default value.
The caching functionality used for speeding up annotation retrieval must be updated to follow the same rules as when using the regular API.
The batch functionality for speeding up annotation changes must also be updated.
Change history logging might be affected as well. Should changes be visible across projects?
Some implementation details The approach taken to implement this feature is to add two columns to the Annotations table.
- project_id: The id of the project the annotation belongs to or 0 for default values
- 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.
When searching for annotations we can introduce filters in HQL/SQL statements:
- where ... project_id = <pid> to find only project-specific annotations (or 0 to only find default values).
- 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).
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.
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.
Change History (30)
comment:1 Changed 4 months ago by nicklas
- Owner changed from everyone to nicklas
- Status changed from new to assigned