Le 11/02/2016 17:40, Nicolas Malin a écrit :
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>
OK that would be service one by one, clear thanks
* 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
You will manage it later?
* 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
Good point, if nobody beats me on it, I'll have a look at that and open Jiras
if needed
Jacques
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
