Content
Options for easier membership management?
Added by Brad Smith over 10 years ago
There are a lot of things I’m liking about OpenProject, but one behavior that keeps proving an obstacle to me is the fact that you can only assign work packages to people who have been designated members of a project. Moreover, it seems that if I add someone as a member of a project, and then create a subproject, they are not treated as members of the subproject. As a result, I have to manually add anyone to whom I might ever want to assign a task to each project. Groups make this a bit easier, but even that is tedious when I have to do it for every (sub(sub(etc)))project.
So, the purpose of this post is first, to check whether I’m missing some option that can make this easier, and if not, to request that such a feature be added or that at the very least that project membership be inheritable by subprojects by default.
Is project membership used for anything other than limiting to whom a task can be assigned? If so, I’d also be curious to know what that is. I can imagine something like an “email all members” feature, but I don’t see one. Even so, an “allow work package assignment to non-members” option would be really great, IMO.
Thoughts?
Replies (4)
Hello Brad,
thanks for your post.
You are right: It is only possible to assign work packages to project members.
The reason behind this is that you typically want to limit the number of users who are possible assignees - to make it easier to find the correct users (as well as for performance reasons).
For instance, when creating a work package all project members are shown as possible watchers (check boxes). If all members in the instance would be displayed, it would be quite difficult to find the correct users.
Aside from defining who can be set as work package assignee, responsible or watcher, a project membership - via the assigned role - defines which permissions a user has in the project. (You can find more information in the OpenProject user guide ).
As you mention you could use a group which includes all users in the instance and add this group to all projects (in which case however the users would have the same permissions across all projects).
An alternative may be to copy projects (e.g. via project settings) and select “Members” to be copied as well.
Thanks for the tip about copying projects. Any chance there might be an option to make subprojects inherit membership from parents? For example, we have a superproject for the development of training content at work, with each course as a subproject. We have a small training team, and everyone should be a member of every project. It would be great if I could just create a group for the training team, make that group a member of the superproject, and have that membership inherit down rather than manually adding the same permission to every subproject or dealing with template projects to copy.
I also feel I must take issue with this statement:
It seems to me that this is limiting functionality to serve an inadequate interface design. In other words, the problem here is not with having a large number of members in a project, but with using checkboxes for this task in the first place. There are many Javascript libraries out there that should make it relatively easy to replace the checkboxes with something more usable and scalable.
For example, here’s one way offered out of the box by jqueryui, or for something more visual, other projects like Moodle and Django use an elegant two-pane selection box like this, and I’m sure there’s a js library out there somewhere that would make something similar easy to implement without coding one from scratch.
Yeah yeah, “patches welcome”, I know, and if I can find the time I’d love to submit one, but in the mean-time I suspect that something like the examples above could be implemented pretty easily by someone familiar with the project, and would both improve the UI and remove an obstacle to better membership management options.
Thanks again for the reply, and sorry for the delayed response!
+1 to an “allow work package assignment to non-members” option.
This is essential for our use case:
- Anyone in our management team can assign a “problem ticket” (a type of work package) to any member of the organisation.
- If we created a group containing all members, and a role where they can view their own “problem tickets”, then that creates a big problem around email notifications. Everyone, by default, will receive everything because they’re now associated with the project.
There’s the possibility that this might also be a bug in the “Only for things I watch or am involved in” email configuration option, but since there is no documentation of that feature (i.e., what does “involved in” mean?), I don’t know whether that’s actually the case.
Either way: I don’t want users to be spammed, but I do want them all to be available for work packages to be assigned to them.
Hello,
is there or will there be an option to send an email to all members of one project?
I don’t mean an email notification but an individual mail written by a project member?
Thank you!