Use case 1: a CANFAR "community" will be a top level construct where all members are "projects". A "community" group should never be made a member of another group and should never have immediate user members. #usage-constraint
Use case 2: only CADC (ops) will create community groups, but someone else will create and manage the member project groups. #admin-constraint
complications:
Some aspects of community groups would need to harder to modify so even admins could not change them; maybe just immutable or maybe only owner can change them (and admin means admin members).
Usage constraints can only be enforced within the GMS itself, not elsewhere (eg grants in other contexts). But if the other context is another GMS service (e.g. ivo://abc/gms?foo is added as a member of ivo://xyz?bar) then we can't really enforce the community group concept in a distributed system.
Project groups could be internal or external (eg SKA) so we probably cannot place any restrictions on them.
Use case 1: a CANFAR "community" will be a top level construct where all members are "projects". A "community" group should never be made a member of another group and should never have immediate user members. #usage-constraint
Use case 2: only CADC (ops) will create community groups, but someone else will create and manage the member project groups. #admin-constraint
complications:
Some aspects of community groups would need to harder to modify so even admins could not change them; maybe just immutable or maybe only owner can change them (and admin means admin members).
Usage constraints can only be enforced within the GMS itself, not elsewhere (eg grants in other contexts). But if the other context is another GMS service (e.g.
ivo://abc/gms?foois added as a member ofivo://xyz?bar) then we can't really enforce the community group concept in a distributed system.Project groups could be internal or external (eg SKA) so we probably cannot place any restrictions on them.