Hi,
I'd propose "close", for closing de period where the data was active...
But i'm not sure if this is not going too far, the algorithm beneath is
not quite simple to be an auto thing. When i develop i would prefer only
updating my GV after setting my closing date.
What do you think ?
Gil
On 06/02/2016 10:18, Nicolas Malin wrote:
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).
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
* 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)
* 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
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 :)
