A data inconsistency caused a customer to not be able to index pages (Worse: Since it created an exception and they were creating data through Scaffolding, it didn't show the exception to them, and the data wasn't saved).

An integrity constraint is that all requirements which are baselined have the status ARCHIVED and a baseline number. All requirements with a baseline number must have the status ARCHIVED. (Requirements without a baseline number can be DELETED, MOVED, ACTIVE).

Steps to reproduce

• Edit the database to set a baselined requirement to DELETED,

• Edit a page with a link to that requirement. It can't be saved.

• Immediate cause: The indexation retrieves all requirements that aren't ARCHIVED and have this spaceKey/key, and yells when it notices that one of them has a baseline number.

Implementation

Inventoried all the ways requirements can be put to DELETED, and check whether a baselined requirement can be set DELETED. Here is the list:

• During migration, if a requirement had no original links, then we'd set it to deleted. It performed this modification for ARCHIVED requirements too, so, we might have migrated wrongly.

• For an not-yet-elucidated cause, I know that some customers have baselines which link to the current version of pages. It shouldn’t happen, since we don’t create those links if we can’t find the versionId. If it happens, it is not stable, as one day the requirement links will be removed, since they don’t literally link to the current version of the page, because they are baselines. Anyway, if it does happen, we’ll just exclude those links from the indexation and write an error in the logs.

• There is no other apparent way to set the status as DELETED for a baselined requirement (besides the two previous cases which shouldn’t happen anyway).

Also, we’ve implemented an upgrade task to reset the status of all baselined requirements to ARCHIVED, when they have been migrated as DELETED by mistake.