We're wrestling with the various ways to 'group' users within Luminis and the implications of using these methods, especially when it comes to targeting users or restricting access. The SunGard doc is a bit confusing. So, I wanted to document my current understanding and raise some questions - hopefully someone with a better understanding will correct me appropriately. (Don't be shy! Thanks.)
Methods of grouping
- Roles
- Imported groups (aka segments)
- User attributes
- Membership in a Group Studio Group
- Membership in a Course
Content
- Fragments
- Targeted content channels
- Targeted Announcements
- Group studio group
Fragments
- Used to set up the layouts that users will see (default tabs and channels)
- Managed via the Fragment Manager [Portal Admin → Manage Fragments]
- Audience can include a combination of: roles, enrolled courses, membership in a group studio group, or user attributes.
Targeted content channels
- Used to target content (duh!) at various populations
- Managed via the Targeted Content Manager [Portal Admin → Manage Targeted Content Channels]
- Audience can include a combination of: roles, enrolled courses, membership in a group studio group, or user attributes.
Targeted Announcements
- Used to send announcements to various populations. Announcements can appear in their email and/or their Personal Announcements channel
- Managed via [Portal Admin → Manage Targeted Announcements]
- Diagnostics available via:
cptool diagnose ta <id>
- Audience can include EITHER a combination of: roles, enrolled courses, membership in a group studio group, or user attributes OR an imported group (segment).
Group Studio Group
- Created via [Groups → Create a Group]
- Managed via [ Admin → Web Applications → Group/Course Studio → Manage Groups]
- "Browsing" of a particular group can be restricted by role only. ie: "The Group Index page currently allows anyone to browse or search for this group. Select one or more roles to control access."
- Membership in the Group Studio group can be populated with an Imported Group (segment). This is done via: [ Admin → Web Applications → Group/Course Studio → Manage Groups → select group → view member → Add Members → Add from Imported Groups]. (Is there a better way to do this?)
Observations and questions
Comments
Populating the membership of a Community Group
First of all, I think that it is great for you to open up this discussion/gathering of knowledge.
I have many thoughts, but think that I will start with a straightforward response to a direct question.
In Group Studio Group you describe a method for populating membership from an imported group. Then ask: (Is there a better way to do this?)
At University of Leeds we are on Luminis III.3.3.114, so things may be different than LP IV. What we do is not necessarily better, but it is more convenient for us.
1) we have a definition file for each auto-populated group, say 6000.def
This contains SQL to extract the group from Banner.
i.e. SELECT DISTINCT ID, AD_USERNAME FROM leeds_custom_table WHERE ests_code NOT IN ('WD','WA','SP') AND (clas_code='05') AND degree_program_code IN ('BS-COMPSCI','BS-ARTCOMP');
2) we run (via crontab) a custom developed job (java program) which
2a) looks up the group id in the GT_GROUP table in Luminis DB
2b) runs the SQL query against Banner DB
2c) writes the membership into a temp table in Luminis DB
2d) updates the membership of the GT_MEMBER table in Luminis DB
The program does basic error handling and can also populate sub-groups.
redefinition - populating groups, using attributes to target
While we have put much effort into grouping users within Luminis,
this does not meet all of our targetting needs. I would see separate
things.
Grouping users in the Group Studio sense - providing access to tools and information through belonging to a defined group.
Broader groupings, termed Role - and also called Access Groups. (Occassionally we set up a temporary role to drive TCC to a specific - one off - audience)
Permissions - a specific kind of attribute that can be assigned to all members of an Access Group (we started looking at these to get the Classifieds channel working)
Externally defined user attributes - i.e. obtained by looking up a user
via PersonDirs.xml in a number of external databases/ldaps (I do not see these as "groupings" per se)
Single sign on - so both username and password allow an external
system to define which information is seen.
Use can be made of all of these to control / target the info and access given
layout template, for default channels and views (in LP IV, fragments)
Targeted content channels
Targeted Announcements
Group studio group
Specific (custom) channels
Many of the things we have started doing involve simple use of the username attribute.
answer to last question (and musing)
You can use automatic batch jobs to create/populate imported groups, we extended this to create the java which populates Community Groups (Group Studio).
We use this technique for having "1st Year Biological Sciences" as an imported group, and we also use it for "2nd Year CompSci with Artificial Intelligence Programme" as a Group Studio Community Group.
Of course, to complicate things we have a "All Research Postgraduate"
as an Access Group (Role).
Our Faculties request the particular groupings they would like and the
type of targetting they aim to achieve. So there are far fewer groupings than we would need to represent the whole of the University infrastructure.
Musing - if you take a combination of attributes, such as username, faculty, school which you can determine via PersonDirs.xml and have
a custom channel that presents several (CWebProxy) webpages to
the user? what is the best way of coping when the student reports
that the information (from the external DBs) is wrong?
Derek