Description
Currently:
When a Subject creates an object in Grouper the system currently assigns "Admin" privileges to that subject if they do not already get "Admin" from inherited privileges to the new object.
Proposed:
It would be helpful, for many use cases, if a Member ( Grouper local cache of the Subject ) could have a configuration that would request that a different Subject be used instead of themselves.
This would be effective with or without Inherited Privileges and should be used drive towards a "group" instead of a "person" being privileged to all objects.
Example cases:
Subject is an "Admin" of a single application in Grouper.
A WebService account (acting on behalf of a connected application/service)
All things they create should default to being owned by a group (Subject) that manages that application instead of the direct subject that created the object.
It would also be helpful if this could be a "list" of values for users who manage more than one application in Grouper. (A "default" could be identified for a Member too.)
The UI could default to the default value and allow the user to select from the list of configured values before/during the create process.
WS could allow the user to supply a value during create or use the configured default value.
It would also be helpful if the default value could be selected based on "location in Grouper" too. (An attribute on a parent stem could help with the selection of the correct value for a Subject. )