Operator with multiple accessgroups pointing to same application
When Pega introduced application-based acessgroup, a new warning was introduced on the Operator ID record when saving with multiple accessgroups pointing to same location:
"Each access group must list a unique application name"
Why must? Really, what is the consequence?
This warning makes sense in a production environment, but not pre-production where users (developers) have multiple roles.
The only consequence I'm aware of is a UI decision that's tricky to override -- the "Switch Application" dropdown actually switches accessgroups. These used to display accessgroups, but I think in v5 or v6 this was updated to display Application name, which was presumed to be more useful for the user. But, clearly, for developers, the accessgroup name is more useful.
Obviously, this should be an overridable switch/preference per user. Or otherwise this should just solely display the accessgroup in the developer dashboard list.
(I'm planning on overriding this for us v6 & v7. One of these days)
***Updated by moderator: Lochan to add Categories***
***Updated by moderator: Marissa to close post***
When Pega introduced application-based acessgroup, a new warning was introduced on the Operator ID record when saving with multiple accessgroups pointing to same location:
"Each access group must list a unique application name"
Why must? Really, what is the consequence?
This warning makes sense in a production environment, but not pre-production where users (developers) have multiple roles.
The only consequence I'm aware of is a UI decision that's tricky to override -- the "Switch Application" dropdown actually switches accessgroups. These used to display accessgroups, but I think in v5 or v6 this was updated to display Application name, which was presumed to be more useful for the user. But, clearly, for developers, the accessgroup name is more useful.
Obviously, this should be an overridable switch/preference per user. Or otherwise this should just solely display the accessgroup in the developer dashboard list.
(I'm planning on overriding this for us v6 & v7. One of these days)
***Updated by moderator: Lochan to add Categories***
***Updated by moderator: Marissa to close post***
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Accepted Solution
Pegasystems Inc.
US
Bence Magyar is the reigning guardrail czar - they recently (in the past year) did an audit of all warnings with PS and this was kept as a moderate data integrity warning. I've always been bothered by this one.
I think at a minimum, changing the language from ‘must' to ‘should'…must be done.
As an aside - data warnings don't get factored into your compliance score or appear on guardrail landing pages. Only rule warnings get indexed for reporting.
Also, Designer Studio menu (from 7.1.7 I think) shows access group label in parenthesis when there are duplicate apps.
Pegasystems Inc.
CA
I think changing the language makes sense. If it's a warning it should say "should" not "must". If it's "must" it would be a failure, not a warning.
Let's see if I can summon someone responsible...
Dennis Grady or Michael Degatano
-Ben
Whoa, wasn't I just in my chair? How'd I get here?
Must is definitely a stretch, I'm not certain it should be a warning at all. I think Jon is right about the reasoning, it's because the switch application option will get confusing when there are duplicates in the list.
What I think I really want is toggles for both. I want my switch application toggle that toggles between the applications I have access to because I think in terms of applications. Then if I have given myself multiple access groups for the same application, I want to have the ability to toggle between them as well and view my current application from those perspectives.
Whoa, wasn't I just in my chair? How'd I get here?
Must is definitely a stretch, I'm not certain it should be a warning at all. I think Jon is right about the reasoning, it's because the switch application option will get confusing when there are duplicates in the list.
What I think I really want is toggles for both. I want my switch application toggle that toggles between the applications I have access to because I think in terms of applications. Then if I have given myself multiple access groups for the same application, I want to have the ability to toggle between them as well and view my current application from those perspectives.
Although to me I think the bigger issue here is we need to rethink what an access group actually is because frankly I find it is one of the more difficult concepts to explain to people. It's not a role, it's not an application and it's not a portal, it's a construct which provides a link between all 3. Recently I've heard the word "persona” thrown around for it. I also noticed in the latest Pega Express we are referring to them as "roles” (which is confusing since roles are also a thing that access groups contain). I think perspective isn't a bad word either. But I feel like when you think about it as first toggle your application then toggle your perspective/persona/role within your application it makes more sense.
Accepted Solution
Pegasystems Inc.
US
Bence Magyar is the reigning guardrail czar - they recently (in the past year) did an audit of all warnings with PS and this was kept as a moderate data integrity warning. I've always been bothered by this one.
I think at a minimum, changing the language from ‘must' to ‘should'…must be done.
As an aside - data warnings don't get factored into your compliance score or appear on guardrail landing pages. Only rule warnings get indexed for reporting.
Also, Designer Studio menu (from 7.1.7 I think) shows access group label in parenthesis when there are duplicate apps.
Pegasystems Inc.
CA
Is it worth changing the language on the guardrail warning? I imagine that is significantly less effort than redefining the concept of an Access Group (I personally like Persona, especially since this is meant for the business user/developer who is defining an application).
--Ben
Pegasystems Inc.
CA
P.S. You should change your avatar from the puppy to something else (your face!)
I'm on a Mesh hunt for people who are puppies.
-Ben
Updated: 29 Apr 2015 12:52 EDT
Pegasystems Inc.
US
Michael,
[Thanks for falling off your chair, right into our new, open community space!]
In the landscape of app dev where role-based access to portals, apps, and other things is well known -- sort of standard, I think that Access Group works just fine -- as long as it's clearly defined and illustrated in Pega Academy courses and in the product doc.
Please let's NOT adopt Persona!
Personas are a well-established UI Design artifact -- one in best practice by the Strategic Apps UX/UI Designers.
For example, see the Pega-internal-only Persona Library.
And, it's that old-fashioned Operator ID that has to go!
(You Pega-insiders have, of course, been watching the Pega-internal-only discussion on Pega Terminology. Yes?
No link here because that's an Internal discussion and this one's an Open discussion.)
-Mary
Pegasystems Inc.
US
I've always ignored this warning too as many operators in my application have multiple access groups that use the same Application. The difference for us is the Roles and Portal that each Access Group uses.
I could be mistaken, but I believe this warning was added, and is considered a data integrity issue, because (starting around 6.1, I think) there is logic somewhere in the system that tries to identify the correct Access Group to use when opening work objects onto new tabs (i.e. Threads) and the engine runs through the available access groups looking for one that sees the work object class, and sets that as the Access Group for that Thread. If you have multiple access groups that have access to that work object, then you're not sure which access group will be selected and the differences in security between those access groups could lead to undesirable/unexpected results. Or something along those lines.
In reality I've never heard of a problem with this but it could be sheer dumb luck based on our security model.
Pegasystems
US
I must admit, I have often copied a rule-application merely to give it a different name, such that my dropdown list on “switch application” shows distinguishable names, despite the fact that I’m really trying to have two different access groups refer to the same rule-application (for example, if what really differs between the two access groups are roles).
/Eric