Add default hierarchy restrictions
What does this MR do and why?
Fills hierarchy restrictions for objective/key result:
- tasks can be assigned to issues
- objectives can be assigned to other objectives (max 9 levels of nesting)
- key results can be assigned to objectives
These rules are not used yet, but will be used later in a follow-up.
Related to #378801 (closed)
Screenshots or screen recordings
DB migration:
$ rake db:migrate:main db:migrate:ci VERSION=20221116143854
main: == 20221116143854 AddOkrHierarchyRestrictions: migrating ======================
main: == 20221116143854 AddOkrHierarchyRestrictions: migrated (0.0189s) =============
ci: == 20221116143854 AddOkrHierarchyRestrictions: migrating ======================
ci: -- The migration is skipped since it modifies the schemas: [:gitlab_main].
ci: -- This database can only apply migrations in one of the following schemas: [:gitlab_ci, :gitlab_shared, :gitlab_internal].
ci: == 20221116143854 AddOkrHierarchyRestrictions: migrated (0.0001s) =============
$ rake db:rollback:main db:rollback:ci
main: == 20221116143854 AddOkrHierarchyRestrictions: reverting ======================
main: == 20221116143854 AddOkrHierarchyRestrictions: reverted (0.0057s) =============
ci: == 20221116143854 AddOkrHierarchyRestrictions: reverting ======================
ci: -- The migration is skipped since it modifies the schemas: [:gitlab_main].
ci: -- This database can only apply migrations in one of the following schemas: [:gitlab_ci, :gitlab_shared, :gitlab_internal].
ci: == 20221116143854 AddOkrHierarchyRestrictions: reverted (0.0002s) =============
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by Jan Provaznik