Feature #1556
closed
Copy users to new projects
100%
Description
I am busy adding projects and subprojects as our use of redmine increases. One of the more tedious aspects is adding the same list of users to each subproject (especially because it is so hard to find them with the order by last name convention used in the users menu).
I suggest an 'Add SubProject' action that would either copy all my users with roles intact from the parent project ready for editing OR let me pick the ones to copy first.
Related issues
Updated by Stephanie Collett almost 16 years ago
+1. This would be nice in our project environment. However, allowing subprojects to have the same users/permissions as the parent project would be +2. Adding new people to projects and subprojects takes a lot of time and is error prone. If there was a way to link subproject users/permissions to parent project users/permissions, then new users would only need to be added once.
Updated by Ewan Makepeace over 15 years ago
There are so many usability issues with the handling of workflows and users that it is hard to know where to begin. In general the Ajax aspects of the UI seem to encourage a style where each change is sent one at a time (rather slow) rather than checking a dozen checkboxes and hitting Submit.
Cases in point:
1) I add a new sub project and must add each user one at a time (specifying a role for each one), waiting for the screen to repaint after each one. VERY tedious. What was wrong with a list of names and a Select All option, then submit? Why cant I name his role for all at the same time?
2) I add a new employee and must add him to all the projects he will touch. Again this is one at a time - why cant I just check all the projects he has access to, specify his role and click Submit?
Updated by Alan Franzoni about 15 years ago
+1
I really think this would be great. IMHO there could be a flag in any project, something like "inherit members from parent project" that can be selected or unselected at will. If unselected, the functionality should stay the same as now.
If selected, things should work this way (something resembling inheritance in OO languages):
- if nothing is changed in the subprojects, its members should be the same as the parent project.
- members can be "locked" in subprojects, meaning that they're not part of the subproject even though they're members of the parent project.
- membership type (manager, developer, etc) can be changed in subprojects; of course this change is not reflected in the parent project.
I suppose this would add a layer of complexity; right now, the field "subproject of" in a project's settings can be changed at any time. If those feature make it into the codebase, i think the "parenting" should be fixed at creation time, and that further "reparenting" should be done via the "move" function.
Updated by Stewart MacArthur about 15 years ago
+1 I agree. This would be a very useful feature and remove some of the tedium when generating projects.
Updated by Eric Davis almost 15 years ago
- Category set to Projects
- Status changed from New to Resolved
- Assignee set to Eric Davis
- Target version set to 0.9.0
- % Done changed from 0 to 100
- Resolution set to Fixed
I just added the ability to copy a project in the Project Administration panel as part of #1125. Would this solve your project when creating a project?
Updated by Eric Davis almost 15 years ago
- Status changed from Resolved to Closed
This issue should have been Closed instead of Resolved.