Adding the system party is not for validation per se, but rather to
record data. It seems that createCustRequest wants to store a
CustRequestRole to store who took the request. Should we observe
that by creating a party for system so that it shows a system party
took the request?
On Dec 5, 2006, at 9:28 AM, Leon Torres wrote:
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]
Best Regards,
Si
[EMAIL PROTECTED]
