...
- Since we only save the HTML of the requirement, and the HTML contains a URL to the image and not the image itself, someone could change the image at the end of the URL, for example by uploading a new version of this image in Confluence.
- Because of this, images in baselines are not guaranteed, since images can be swapped with other ones,
- Because of this, Jira will attempt to display the image, but may fail if the user is not conneted to Confluence, or if the applink between Confluence and Jira doesn't allow cross-domain images.
The 1-to-1000 issue
- We don't support links from 1 requirement to 1000 dependencies, or 1 Jira issue to 1000 requirements.
- We expect requirements to be linked to 3 to 20 dependencies.
- We expect requirements to have 10 to 50 properties.
- The problems you would meet would be:
- The hard limit in Jira,
- In the traceability matrix, the backend has to load all the dependencies despite only showing the first page (the size depends on your choice, let's say 600 rows).
- The popup in Confluence will be long to load, and the contents of all requirements are preloaded when the page is loaded.
Workflows and validation
- Requirements don't have a status.
- Customers manage the status by using a
macro, and changing the text and colour manually.Status colour Green title Status - Customers also use EDM "Easy Dropdown Macro" to have a dropdown as a status.
- The drawback is, there is no validation of the permissions associated with the status change.
- The other drawback is, people do spelling mistake, and they can type "Valiid". We are planning on introducing a rules engine in the medium term. As usualy, please don't count on it until it is done and published.
...