In general security checks should follow this sort of pattern:
IFF has General Permission THEN allow
ELSE IFF has Limited Permission and is related to entity with X role
THEN allow
ELSE IFF logged in user has partyId that equals entity.partyId THEN
allow
ELSE reject
Not everything will have all of these conditions, but in general
there should be general/admin permissions that are checked before the
userLogin's partyId is checked.
Is the createCustRequestRole service the only one you're running into
problems with or are you finding this as a more general issue?
-David
On Dec 4, 2006, at 5:55 PM, Si Chen wrote:
Hi.
We're having some problems doing certain things because the
"system" userlogin doesn't have a party associated with it. Should
we create a "system" Party? Or should we fix whatever service so
that if userLogin.partyId == null then don't do what it needed that
to do (though I'm not sure it'll actually work in all cases that
way...)
Best Regards,
Si
[EMAIL PROTECTED]
