From: Krzysztof B. <kb...@un...> - 2020-08-28 17:39:34
|
Dear Sander, W dniu 27.08.2020 o 10:09, Sander Apweiler pisze: > Dear Krzysztof, > I try to explain it. We start with one group, let's call them HIP. > Within this group several projects are funded and the projects have > different lifetimes and different resources. The people who are working > in the projects are very volatile, that there is an ongoing adding and > removing users from the projects. The projects are subgroups in unity. > > So the idea is to have a HIP-manager who creates the subgroups > (projects in HIP) within the HIP group. The information about the > funded projects, e.g. lifetime, or PI, is only known within the HIP > group for this reason the handling of the subgroups should be handled > to the HIP-group. Because the HIP-manager is not involved in the daily > project work and membership updates are delayed if the HIP-manager > needs to update it, the plan is to have project-managers that do the > membership-management in their own projects (unity subgroups). Because > different resources are bounded to (sub-)group membership we want to > prohibit the manipulation of other subgroups where the project-manager > is not member or the parent group we want to have the hierarchical > administration permission. The GDPR is another issue why project- > managers should not have access to the full tree. > > The process of creating and deleting projects within HIP (subgroups in > unity) is ongoing. For this reason we can't do an initial delegation to > HIP to create the subgroups, revoke revoke the delegation after it and > delegate the subgroup management. > > The HIP-group is only one, we will have multiple of such groups. The > manual subgroup creation and delegation creation does not scale very > well for the unity administrators. The fast increasing number of > registration and enquiry forms is another issue. If unity can handle > this can be estimated by you much better. > > Hopefully this explains why the suggestion to delegate the subgroups > does not fit for our use case. Thanks for the explanation, I guess I understand where this problem is. Let me ask one follow on question, to confirm my understanding. So let's imagine that the main unity admin created HIP and delegated its management to some HIP-wide admin. Now the HIP admin will add/remove projects under HIP from upman what works fine. Let's say the projects under HIP are 'hop' and 'clap'. HIP admin wants to delegate hop and clap management to other ppl. But it can be done only by the main Unity admin what is cumbersome and is the problem described here. Did I get this correctly? If yes then I, yes we have a feature gap here. We would need something like this: 1. extra permission (settable by the main unity admin on projects admin): allow-to-re-delegate-subgroups 2. in upman (only for ppl with the permission from the point above) add option to delegate subgroup management separately (as a sub project). 3. in upman allow to control sub-project admins (what is separate from the main project admin) 4. internally we would need to take care of deriving all forms for the sub project from the main project forms That isn't a small change, but also doesn't sounds as something terribly complicated. Best Krzysztof |