Skip to Content.
Sympa Menu

grouper-dev - [grouper-dev] organizing services in grouper

Subject: Grouper Developers Forum

List archive

[grouper-dev] organizing services in grouper


Chronological Thread 
  • From: Chris Hyzer <>
  • To: Grouper Dev <>
  • Subject: [grouper-dev] organizing services in grouper
  • Date: Tue, 27 Nov 2012 15:20:58 +0000
  • Accept-language: en-US

Im working on this task now:


I think we should simplify what we had previously discussed.

I originally thought you could tag the following objects in grouper with a service tag: groups, roles, folders, permission definitions

However, I think there are two reasons to simplify to mandate that you can only assign the service tag to folders.

1. The queries will be a lot simpler, quicker, and more reliable (and even possible)
2. It is a best practice to have a root folder for a service
3. Makes it easier (and less chaotic) to setup a service, just assign one attribute to one folder

If you have a root folder for a service, and you use groups outside of that folder in that service, then you should probably create that group in the service folder and add the external group as a member (another Grouper best practice).

Here are some more thoughts about the direction of this enhancement

 - service tag can be assigned to a folder
 
 - any objects in the folder or subfolder are objects of the service
 
 - users can be an admin of a service, or a user of a service (these are virtual roles for UI purposes)
 
 - a service admin has create/stem privileges on a service folder, admin/update on a service group/role/entity, or admin/update on a service attribute/permission, or admin on the service attribute
 
 - a service user is a member of a service group/role (including having permissions)
 
 - note, just because a service admin can admin one object in the service, does not mean they can edit any other objects
 
 - service users do not need to be able to view the service attribute
 
 - a service has attributes: name, display name, description.  Currently those are just in the attribute name object.  Other metadata?  Perhaps, e.g. a URL, a help email or URL, etc.  Might want to have one service name per service attribute definition
 
 - note, for permissions, either the role or the permission definition needs to be in the service folder or subfolder, or both
 
 - in the API / WS you can get:
  - the users of a service (subjects and/or members?)
  - the admins of a service (subjects and/or members?)
  - groups in a service that the subject is a user of
  - groups in a service that the subject is an admin of
  - folders in a service that the subject is a user of
  - folders in a service that the subject is an admin of
  - attribute/permission definitions that the subject is a user of (api only to start)
  - attribute/permission definitions that the subject is an admin of (api only to start) 
  - attribute/permission names in a service that the subject is a user of
  - attribute/permission names in a service that the subject is an admin of
  - memberships of groups/roles of a service that the subject is a user of
  - privileges of groups/roles of a service that the subject is an admin of?
  - permission assignments of groups/roles of a service that the subject is a user of
  - privilege assignments of attributes/permissions of a service that the subject is an admin of?
 
I will be working on this, so let me know if you have thoughts asap :)

thanks,
chris 
 



Archive powered by MHonArc 2.6.16.

Top of Page