In line
The idea, when you call cancel :
* check if a field date is present on IN service fields and isn't a
pk -> set at now
What do you mean exactly by a "field date", how do you discern between
estimatedStartDate and estimatedCompletionDate (of course only the
last should be set to now)
Depend on your service definition, with your example it would be like
that (warning it's stupid example) :
<service name="completeEstimationTask" engine="entity-auto"
default-entity-name="WorkEffort" invoke="expire" auth="true">
<description>complete the time associate to a task</description>
<auto-attributes mode="IN" include="pk" optional="false"/>
<attribute name="estimatedCompletionDate" type="Timestamp"
mode="IN" optional="true"/>
</service>
* else check if a field like %statusId is present on IN service
fields and isn't a pk -> check the related cancel status (if possible
to resolve it by the StatusType)
This seems more normalised, I though found a fromStatusId in
changeOrderItemStatus service, and checkStatusId in
updateStatusImageManagement and sprintStatusId + custRequestStatusId
in autoScrumNotification
Yes and we would be manage by default the statusId field or the field
present on the service. But I prefere exclude this case
* else check if a thruDate is present and isn't a pk and it's empty
-> set at now
* else check if a%thruDate is present and isn't a pk and it's empty
-> set at now
Looking at services definitions (and not implementations so could be a
false issue), it seems we need to handle cases like
thruTransactionDate or thruEntryDate also, etc.
hmmmm yes it's true
if one case match, call update
After we would be use the pattern like cancelProductCategoryMember.
<service name="cancelProductCategoryMember" engine="entity-auto"
default-entity-name="ProductCategoryMember" invoke="cancel" auth="true">
<description>Cancel a ProductCategoryMember</description>
<permission-service service-name="genericProductPermission"
main-action="UPDATE"/>
<auto-attributes mode="IN" include="pk" optional="false"/>
</service>
As usual any suggest are welcome :)
This sounds good to me, we just need to be sure we review all things
before committing.
BTW I was reviewing last Nicolas's entity-auto changes (r1726323,
r1726327, r1726334, r1726338)
and stumbled upon things which make me wonder
:)
Why services like
createTaxAuthority have a acctgBasePermissionCheck (r1726327)
For the simple to entity-auto conversion, i didn't use all my brain,
when I detected a permission present en minilang, I recreated it on the
service definition. But right some time I had the same reflexion ... why
? But my response have been en general "just convert they are too work
on it" :)
while services like createCreditCardTypeGlAccount have none (r1726334)
This was before Nicolas's changes, so just wondering. I guess because
those services are only called OOTB from screen/s where
acctgBasePermissionCheck is already used. But what if they are used
otherwise (eg as an API)?
+1, is now easier to detect some incoherence like this and improve the
business API
Nicolas not a big deal, but should we not have copied this comment
above createCommunicationEventPurpose service definition?
- <!-- since these ancillary operations on communication event
cause them to be updated,
- they will all use the CME_UPDATE permission -->
It's actually PARTYMGR_CME_UPDATE.
Mmm... after deeper review not sure it adds much since it's clear at
bottom of partyCommunicationEventPermissionCheck, but I let it to show
I reviewed :D
Good point, It's possible that I made a miss !
I will continue the review for r1728261 and r1726542. It was really a
good idea to switch to entity-auto, things are much clearer.
Oh I appreciate ! Thanks Jacques.
I have few service to convert on entity-auto, but on my next email, the
few is hard to convert without community decision ;)
Nicolas
