Targeted Announcement Permissions and Grants
Mon, 2008-06-30 20:59 — bwalker
Holy cow. I just spent the morning trying to setup user access to Luminis 4 Targeted Announcements. The experience has left me visibly shaken. I now feel like a character in a Kafka novel.
I tried to do it without the manual, because, hey I'm a pretty smart guy, managing Luminis for three years. No go. Unfortunately, once I did crack the manual, my confusion was not abated.
Does anyone have any guidelines, experience, or wisdom on this topic?
Thanks, Bob.
- bwalker's blog
- Login or register to post comments
Hack Your Knowledge
Recent blog posts
- Help!! Luminis 4.1
- Portal for Prospects - facilitation of user accounts from Banner
- receiving error while installing on Solaris
- PermGen space on Windows
- Luminis IV integration with Lotus applications
- Anyone do a complete SunONE migration to Exchange?
- SAF: Is it required if using ILM and Active Directory
- Calendar Migration: SunOne to Exchange 2007
- IMAP on Luminis IV
- cptool list sessions via JSP
Developer Links
Poll
What is your estimated peak concurrent usage (sessions) on Luminis at your institution?
More than 2500
23%
Between 2000-2499
0%
Between 1500-1999
5%
Between 1200-1499
15%
Between 900-1199
5%
Between 500-899
23%
Fewer than 500
30%
Total votes: 40
- Login or register to post comments
- Older polls
Syndicate
Comments
Various tips and tricks
First of all, make sure you know what you want to accomplish. For Targetted Announcements the primary thing you are setting up is who (the grantee) can send to whom (the audience). Once you have that policy defined (and I assume you do) then you can begin setting them up by defining each separate group to which someone has permission to send announcements and then defining the group that has the permissions.
One thing you cannot do in the permissions and grants setup is define the audience relative to the grantee: you cannot set up a group of departmental secretaries and say they can send to any student in the same department. So if you that is your policy you will have to define each departments grant separately: The math secretaries will be granted the math department students as an audience and so on.
Once a user has been granted permission to send announcements to a particular audience, they can create additional conditions when the send an announcement to further restrict their audience. However, they cannot expand their audience as the audience definition is 'AND'ed into any additional restrictions they create.
That brings up another point: AND and OR can be confusing depending on how you look at it: AND further restricts the audience, while OR adds a new group of people to the audience. So to say "I want to include all people who meet criteria A and all people who meet criteria B" who put it in the grant as "A OR B".
Of the 4 basic criteria listed, the "Role" criteria deserves special mention. A role is based on transitive inclusion in an access group. That is, if a person is a member of an access group which is s a sub group of access group 'A', then they have role A. This is different than the 'Role' user attribute, which would only give direct members of the A access group.
My misconceptions
Thanks for the response,
I knew that there were going to be major changes in the permissions part of TA for LP4, and that I would figure them out once they arrived. I'm starting to think that my problems are with what I expected (and perhaps how I would have done it) and what was delivered.
For example: I want to set up a group of people who will be able to send announcements to Faculty, Employees, or Administrators. Depending on the announcement, they may send to any combination of the three roles they have access to. My assumption was that when creating the announcement, they would be presented with a dialogue where they could define their target audience for that specific announcement, choosing from the roles they were allowed to send to.
This does not seem to be the case. It looks as if all three roles are ORed and you can't change it.
As you mentioned, any further definitions are ANDed. I suppose if they wanted to send to only Faculty they could NOT the Employees and Administrator roles, but that's a bit arcane.
As well, I find it strange that once I have limited this group to only send to certain roles, they still have access to *every* role on the system, in order to modify their selection. I was hoping for a system where the user didn't even know there were other roles on the system but the ones they are allowed to use.
So, it looks like in order to achieve what I want, a user being able to send an announcement to any combination of Employee, Faculty, or Administrator roles, I would need to create 7 different permission groups.
Am I missing something?
Bob.
Additional thoughts
One minor correction to something you said: If someone was granted rights to send to "Administrator or Faculty or Employee" and wanted the email to go to Faculty, they would "AND" in the Faculty role, rather than the negations of the other roles. Doing what you suggested above would give Faculty who are not Employees and not Administrators (very likely an empty group).
For your particular example, since Faculty and Administrator are probably both subsets of Employee, you could just grant them permission to the Employee Role. Same is not true if the audience is something like Faculty OR Student.
You might want to experiment with the results of granting someone multiple audiences. I am not sure what the system presents to the sender: it could conceivably just OR all of the audiences together rather than letting the person choose the starting audience form among them.
I think the thing I do not like is that end users have to understand this boolean logic to restrict their announcements beyond their default audience, something which even experienced programmers can have trouble getting right.
More boolean logic
I think I see what you mean about not using NOT. But it is still awkward.
In my example of a user with an allowed audience of Faculty, Employees, and Administrators wanting to send just to Faculty they would choose to AND with Faculty instead of NOT the other two.
The results would be:
(Faculty OR Employees OR Administrators) AND Faculty -- with the end result being Faculty.
I can't wait to explain this to users.
Some users can understand boolean logic, but not this version. I'm having enough trouble myself.
I still think a better implementation would have been to provide the user with a checkbox for each permission for that audience group.
You are not alone
Bob,
Sorry, I don't have any constructive advice for you on how to get your brain around that mess they call a user interface. It was designed by geeks, for geeks.
However, I can offer you some emotional support: it's not you!! You are not alone in your frustration. I had one very smart "power user" type of targeted announcer on the phone crying to me, yes literally in tears, because she felt too stupid to understand what was going on with the new system. I had to tell her that it wasn't her, either.
I hope, at least, your eyes are dry. :)
Todd
Glad I'm not alone
Thanks for the words Todd. I got to thinking it couldn't be me, but It's good to hear some other feedback. BTW, I don't cry about Luminis anymore. Sometimes I fix it and sometimes I don't.
Alas, not only is the new TA system notoriously difficult to use, the email portion is seriously crippled. It took 1.5 hours to send one email in a test I did. At first I thought there was something wrong with our new server, but then I saw :
FAQ 1-3T17GP Luminis IV Targeted Announcement emails taking long time to deliver.
Before Luminis Platform IV, a Targeted Announcement (TA) could only be targetted to a union of sets (roles/majors/imported groups). With the introduction of Fine-Grained Access Control (FGAC) a TA can now be targetted to any Boolean expression of sets. In most ways, this would be considered an improvement. However the mechanism that Luminis uses to create "filter groups" using FGAC has one downside: Luminis can't know which users satisfy the filter group expression, it can only know whether or not the current user satisfies the filter group expression.
Because of this, Luminis can't say how many users are targetted. Also, Luminis can't directly send email to the targetted users. Instead Luminis has to simulate a login for each user in the system and ask about this (now current) user being in (satisfying) the filter group expression.
...workaround snipped...
Yikes! A login for each user to see if they belong to the inclusion set! Unbelievable.
Bob.