Le 06/02/2016 10:18, Nicolas Malin a écrit :
Hi guys,
During the simple crud service to entity-auto, I detect the remove(Entity) service that didn't remove the generic value from the data base put only
set the field thruDate to now.
I think this operation isn't in coherence with the service name, yes generally the operation is logical on context but not really on the abstract
interface. I wish introduce a new operation on the entity-auto invocation : cancel (or an other nice word that you fell better).
I agree with Pierre's proposition, *"expire"* seems the right word for me too
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)
* 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
* 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.
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)
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)?
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
I will continue the review for r1728261 and r1726542. It was really a good idea
to switch to entity-auto, things are much clearer.
Jacques
