I was pondering how best to support On Behalf Of (OBO) in my iParts in addition to the existing support for Logged In ID and Selected ID, when I realized that ASI may have already solved part of this puzzle.
Are there any guidelines or patterns for how these three entities should be used? My initial perception is that OBO substitutes partially for Logged In ID, but things can get really fuzzy when you start playing with combinations.
Here are some example scenarios I'm concerned about. In each case, L is the logged-in ID, S is the Selected ID (falls back to L when blank) and B is OBO (falls back to L when blank).
- If B has more rights than L, should the user have more rights than normal or the same? (Navigation items, queries and other documents, fields they can see/edit)
- How about when B has less rights than L? Should the capabilities be reduced so the user is seeing exactly what B would see?
- If someone logs in but has not searched for a record (S = L), but has entered OBO (B != L) and goes to an "edit my profile" page, should they edit the B or the L record?
- User logs in, finds a record S, and engages OBO. Now they click "Change" and go back to "their own" record. Would that be L or B?
- When OBO is in effect, should change log entries and LastUpdatedBy fields be attributed to B or L?
- If L is a CompanyAdministrator and B is not, can the user do CompanyAdministrator type things on behalf of B?
- If L and B have different member type edit rules, which rules apply?
- If L and B have different access keywords or roles, which rules apply?
- If L is registering B for an event, should they see the only the choices B can see ("true to B's view") or should their permissions allow different choices ("L can perform an override", but also "L can't use OBO to get around a security rule")?
- Does IQA use L or B for @Me, or is there a way to specify which is intended?
- If the user engages OBO, and by being B is able to see different search results to get an S they shouldn't normally get, what happens (and what should happen) when OBO is disengaged?
I think that's probably enough.
For most of these, I can see arguments for either answer. I also recognize that some situations will call for exceptions. I'm not here to design the feature, nor bury it, but to understand it. I'm really hoping ASI has come up with a clear definition of how it is meant to work that clarifies the scenarios above and many others like them.
-- Bruce Wilson
Director, Technology Solutions