part of request #39352 Program add to top backlog post-action should ignore Teams How to test: - Set up a Program project (A) that will serve as template. - Create a new B project from a project that you are admin of, and select A as template. Create the project. - In project B, go to Program Management administration. You should see the same configuration as in project A: - The Program increment tracker is configured with the duplicated tracker. - The custom labels for Program increment (and Iteration, if any) are set. - The Iteration tracker (if any, it is optional) is set with the duplicated tracker. - The trackers that can be planned in PIs (Features and Enablers) are set with the duplicated trackers. - The user groups that have permission to plan (and prioritize) are set with the duplicated user groups. - Still in project B, go to the Features tracker administration > Workflow > Transitions. When you click on the "To plan" state config column, you should see the "Add to top backlog" post-action is configured. Its name is not blank, the selectbox shows it in the list. Same for "Scheduled" and "WIP" columns. - If you try to trigger the post-action, it will continue doing nothing. This will be addressed in a further commit. Why? This completes the project inheritance (or "duplication") for Program Management config. Creating a project template without any teams is now possible, and new programs will finally inherit the configuration of their template. The config inheritance was required for post-actions too. Without it, Program Management does not know which trackers can be planned in PIs (Features and Enablers) and does not allow any tracker to list the "Add to top backlog" post-action. Notes: On an architecture standpoint, the Certificate objects are now built by the adapter TrackersDuplicatedHandler. Since we are in the context of a project duplication, we are sure that the trackers from the tracker mapping exist and are part of the new project (because the code in Trackers just created them). Similarly for user groups: the code in core just duplicated the user groups and created the dynamic ones. The domain does not need to do double-checks and should not "issue" certificates: they come from verifications done outside the domain, in adapters. Change-Id: I448ab599853bdaa0d38cea76ecd6f58d0360a91d

+740 −288

Author

Joris MASSON (jmasson) 2024-10-01 15:02

Committer

Joris MASSON (jmasson) 2024-10-03 16:39

Hash e6cb7a06325005d79e0e2cb2f681fe79f9ab95aa

Parent bfd15e375d19a420a2b54d8384c8dd469b8f81e3

Reference git #tuleap/stable/e6cb7a06325005d79e0e2cb2f681fe79f9ab95aa