So, I had an interesting problem that I had not come across before. In my REST controllers I have a baseQualifier() which restricts objects to those that the user has access to. This base qualifier is used for the FetchSpec in the indexAction and used for in-memory evaluation to check object access privileges for single object actions such as show and update.
In one controller I had a qualifier keypath (constructed using ERXKeys of course, but just keeping it simple here to illustrate) that qualified Prospect objects (basically mailing name/address objects):
prospectLists.campaigns.program.location.customer.reseller
The first key is a flattened many-to-many.
The second key is a toMany
The remaining keys are toOne.
The qualifier is basically
new EOKeyValueQualifier("dataLists.campaigns.program.location.customer.reseller", EOQualifier.QualifierOperatorContains, reseller);
This qualifier returns the correct objects when used in a FetchSpec.
However using the same qualifier.evaluateWithObject(...) against any of the objects returned in the fetchspec is false!
Debugging shows that for in-memory evaluation, we have an array of arrays of 'reseller', instead of the expected array of 'reseller' objects, which probably makes sense since the keypath is toMany.toMany.toOne.toOne.toOne.toOne.
The workaround for this rest controller was easy, but it raises the question:
Should we expect in memory evaluateWithObject to always be true on objects that the qualifier fetches with SQL?
Should valueForKeyPath default impl. return a flattened array of objects, or should the qualifier class flatten the array of objects in evaluateWithObject, or ........?
Any opinions?
Regards, Kieran
|