Tip: The only difference between a simple “key suggestion” and a requirement type is having a name. When you add a name, it gives you access to all of the options. (See docs for Key Suggestions)
New in Requirement Yogi 4.0! In 4.0.0, Key Suggestions were replaced with Requirement Types. It’s key suggestions on steroids: Same features by default, and administrators can add the validations, templates, etc. |
Requirement types fulfil 3 needs:
Defining key patterns: As a project is gaining maturity, key patterns for requirements are established. Administrators can define which are the main keys, and even lock down the keys that can be inserted in spaces,
Validations: Administrators can define properties and dependencies which are required for a type of requirement.
Templates: When users insert such keys in an empty table, it will setup the table with all the properties, by default.
We only display invalid requirements from requirement properties, not optional properties.
We display a warning in the byline. When users click on it, invalid requirements appear as a red pill.
Bonus: When a table is incorrectly formatted, for example when the first row is made of gray cells but not headers, we will display it as a warning.
The “red pills” only appear if the user clicks on the validations, at the top of the editor.
When users insert a new requirement in a new page, which belongs to a Requirement Type, it creates the entire table:
Inserting with template.movIf requirements are already inserted, then “Quick Fix” will also update the table dynamically:
Validations are what will let you know if your requirements comply to their type or not.
Validations can only be run in two ways:
When a page is reindexed (all validations will be run),
When a user clicks “Play” on a requirement type (only one validation will be run - requires EDIT permissions on the space),
Note that it is not possible to rerun all validations in a space.
Required (red) fields are displayed in view mode,
Required (red) and optional fields (yellow) are displayed in edit mode,
The columns of required and optional properties are inserted in empty tables. They won’t be inserted once the tables have some amount of text.
“Quick fixes” can add more columns, and they are suggested next to red messages in the editor.
Only space administrators can configure requirement types. Users have access to this screen in read-only mode, the only action they can perform is reset the sequences.
Properties are described as a horizontal table, so it looks like the final page.
Tip: The only difference between a simple “key suggestion” and a requirement type is having a name. When you add a name, it gives you access to all of the options. (See docs for Key Suggestions)
People who can view the space can list the key suggestions, requirement types and their properties.
People who can edit the space can run the validations of single requirement types, and of course edit pages and generate new keys based on suggestions. They can reset the sequences. If the keys are not locked down, then editing pages will automatically add new key suggestions.
Space-admins can create, update and delete requirement types, and lock down the keys.
We have limits for the number of validation messages generated by page. Currently, the limit is 200 SQL requests per run, 1000 messages and 5 seconds, and the limit of requirement types that can apply to a single page is 20.