The code in question is as follows (inside createCustRequest service):
<if-compare-field field-name="parameters.fromPartyId" operator="not-equals"
to-field-name="userLogin.partyId">
<set from-field="newEntity.custRequestId" field="takerMap.custRequestId"/>
<set from-field="userLogin.partyId" field="takerMap.partyId"/>
<set value="REQ_TAKER" field="takerMap.roleTypeId"/>
<call-service service-name="createCustRequestRole" in-map-name="takerMap"/>
</if-compare-field>
If we submit system UserLogin, the service createCustRequestRole fails because
it tries to use a null partyId as a primary key.
Perhaps this piece of code is assuming partyId is always present in UserLogin
and needs to be fixed?
- Leon
David E Jones wrote:
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]
