Description of problem: Currently the practices for reassigning default assignee, default qe, & default docs are lacking, we need a workflow to allow this process to be managed by the associated team without granting them editcomponents on a product. To allow users limited access to make component changes we should create a workflow specialized to this use case. * There should be a form that allows a user to load, and filter, components with an associated team and change roles they are authorized to change. * An associated team is: # The default Agile Team on a product or component # Or the Team for the default Agile Pool on a component * A user is authorised to change a role when: # They are currently in that role # or the user has one of the noted roles[1] in the associated team * Once a request is made the request will be auto-approved if: ** the new user is a member of the associated team ** or if the requester is in a noted role in that team. * If it can't be auto approved then an issue opened and users in the noted roles are CC'd for their approval. Anyone of them can approve it. Products wishing too onboard to this process will need to set-up agile teams and assign them to their products or components. 1: Noted roles: Product Owner, Program Manager, Team Lead, Scrum Master.
I like this workflow as it allows engineering to self service default assignee for components which is very frequent request.
> Products wishing too onboard to this process will need to set-up agile teams and assign them to their products or components. Hi Jeff, what does that mean for the git way of updating default values? Would it still be available to onboarded teams, non-onboarded or both? I am afraid that if the workflow would require teams to maintain their lists of team members it would become out of date. Most probably they would stick with having only the noted roles defined (OTOH that could work quite well too). Btw, assuming that changes are being approved by the new owner, what options does the team have to get rid of a package that was incorrectly assigned to the team?
(In reply to Karel Srot from comment #2) > > Products wishing too onboard to this process will need to set-up agile teams and assign them to their products or components. > > Hi Jeff, > what does that mean for the git way of updating default values? I'm hoping the git version goes away. Imagine if you will the bug bulk edit page, but with lists of components rather than bugs. Click click, change change, clickety submit, all your components updated. > Would it > still be available to onboarded teams, non-onboarded or both? I don't know what you mean by that. > I am afraid > that if the workflow would require teams to maintain their lists of team > members it would become out of date. Most probably they would stick with > having only the noted roles defined (OTOH that could work quite well too). This is fine, being in a bug role allows you to change things. Being in a team role allows you to change things. > Btw, assuming that changes are being approved by the new owner, what options > does the team have to get rid of a package that was incorrectly assigned to > the team? Presumably you talk to program management, who have that new Thunder Dome and ... Maybe we could allow people in the "Noted roles" of the current team to change the default pool as well, that would change the team owning it. I think we'd need someone from program management to sign off on if or how we'd allow the default pool to be emptied.
After discussing this off bug we have decided on a simpler set of ACLs. A user is allowed to manage components in the new UI when: They have editcomponents right on the product They are in the component's default pool's team They are in the component's sub_team The new UI has been deployed to the devel servers should anyone wish to test it. It is available once logged-in in the menu "My Links"->"Workflows"->"Management Components". The dump is fairly recent so should be indicative of production data. https://bzweb01-devel.app.eng.bne.redhat.com/
Can we add a filter to limit number of component showing on the page? Select product Fedora and click View takes way too long to fetch the table.
(In reply to Lianghui Yu from comment #5) > Can we add a filter to limit number of component showing on the page? > Select product Fedora and click View takes way too long to fetch the table. Not for this use case. Fedora will never use this so we aren't pursuing support for it.
Tested a lot and the function behaves as expected, Detailed information is in document of ManageComponents. Cover with automatic case coming soon. Result: PASS
This change has been deployed to the pre-production infrastructure at https://partner-bugzilla.redhat.com
This change is now live. If there are any issues, do not reopen this bug. Instead, you should create a new bug and reference this bug.