entity-auto and cancel operation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

entity-auto and cancel operation

Nicolas Malin-2
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 :)
Reply | Threaded
Open this post in threaded view
|

Re: entity-auto and cancel operation

Gil Portenseigne
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 :)

Reply | Threaded
Open this post in threaded view
|

Re: entity-auto and cancel operation

Julien NICOLAS
I like the idea, when we call delete I imagine that the data is deleted
from the database.

As Gil said, cancel is not the word, close seems better.

But, what's happen if I call delete ? Do you plan to delete all
dependent entity ?

Julien.

Le 06/02/2016 17:09, gil portenseigne a écrit :

> 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 :)
>

Reply | Threaded
Open this post in threaded view
|

Re: entity-auto and cancel operation

Pierre Smits
What about 'expire'? Seems also appropriate.

Best regards,

Pierre

Op zaterdag 6 februari 2016 heeft Julien NICOLAS <[hidden email]>
het volgende geschreven:

> I like the idea, when we call delete I imagine that the data is deleted
> from the database.
>
> As Gil said, cancel is not the word, close seems better.
>
> But, what's happen if I call delete ? Do you plan to delete all dependent
> entity ?
>
> Julien.
>
> Le 06/02/2016 17:09, gil portenseigne a écrit :
>
>> 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 :)
>>>
>>
>>
>

--
Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
Reply | Threaded
Open this post in threaded view
|

Re: entity-auto and cancel operation

ahmad ludin
Like pierre suggested, we could call it: endDate or delimit or expire
On Feb 6, 2016 2:54 PM, "Pierre Smits" <[hidden email]> wrote:

> What about 'expire'? Seems also appropriate.
>
> Best regards,
>
> Pierre
>
> Op zaterdag 6 februari 2016 heeft Julien NICOLAS <
> [hidden email]>
> het volgende geschreven:
>
> > I like the idea, when we call delete I imagine that the data is deleted
> > from the database.
> >
> > As Gil said, cancel is not the word, close seems better.
> >
> > But, what's happen if I call delete ? Do you plan to delete all dependent
> > entity ?
> >
> > Julien.
> >
> > Le 06/02/2016 17:09, gil portenseigne a écrit :
> >
> >> 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 :)
> >>>
> >>
> >>
> >
>
> --
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
Reply | Threaded
Open this post in threaded view
|

Re: entity-auto and cancel operation

Jacques Le Roux
Administrator
In reply to this post by Nicolas Malin-2
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

Reply | Threaded
Open this post in threaded view
|

Re: entity-auto and cancel operation

Julien NICOLAS
In reply to this post by Pierre Smits
+1

Le 06/02/2016 20:54, Pierre Smits a écrit :
> What about 'expire'? Seems also appropriate.

Reply | Threaded
Open this post in threaded view
|

Re: entity-auto and cancel operation

Deepak Dixit-3
'expire' sounds good.

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com

On Sun, Feb 7, 2016 at 8:12 PM, Julien NICOLAS <[hidden email]>
wrote:

> +1
>
>
> Le 06/02/2016 20:54, Pierre Smits a écrit :
>
>> What about 'expire'? Seems also appropriate.
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: entity-auto and cancel operation

Nicolas Malin-2
Ok expire have the most consensus :) so I will do the improvement with it.

To ensure that the new action will don't create any doubt I will exclude
the status case to manage only expiration date cases.

Thanks all for your comments !

Nicolas

Le 08/02/2016 05:51, Deepak Dixit a écrit :

> 'expire' sounds good.
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
>
> On Sun, Feb 7, 2016 at 8:12 PM, Julien NICOLAS <[hidden email]>
> wrote:
>
>> +1
>>
>>
>> Le 06/02/2016 20:54, Pierre Smits a écrit :
>>
>>> What about 'expire'? Seems also appropriate.
>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: entity-auto and cancel operation

Nicolas Malin-2
In reply to this post by Jacques Le Roux
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
>
Reply | Threaded
Open this post in threaded view
|

Re: entity-auto and cancel operation

Nicolas Malin-2
In reply to this post by Nicolas Malin-2
Patch available here https://issues.apache.org/jira/browse/OFBIZ-6892

Nicolas

Le 11/02/2016 17:06, Nicolas Malin a écrit :

> Ok expire have the most consensus :) so I will do the improvement with
> it.
>
> To ensure that the new action will don't create any doubt I will
> exclude the status case to manage only expiration date cases.
>
> Thanks all for your comments !
>
> Nicolas
>
> Le 08/02/2016 05:51, Deepak Dixit a écrit :
>> 'expire' sounds good.
>>
>> Thanks & Regards
>> --
>> Deepak Dixit
>> www.hotwaxsystems.com
>>
>> On Sun, Feb 7, 2016 at 8:12 PM, Julien NICOLAS
>> <[hidden email]>
>> wrote:
>>
>>> +1
>>>
>>>
>>> Le 06/02/2016 20:54, Pierre Smits a écrit :
>>>
>>>> What about 'expire'? Seems also appropriate.
>>>>
>>>
Reply | Threaded
Open this post in threaded view
|

Re: entity-auto and cancel operation

Jacques Le Roux
Administrator
In reply to this post by Nicolas Malin-2
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
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: entity-auto and cancel operation

Nicolas Malin-2
Le 11/02/2016 22:51, Jacques Le Roux a écrit :

>>>>  * 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?
If you call a service like that :

<service name="cancelInvoice" engine="entity-auto"
default-entity-name="Invoice" invoke="expire" auth="true">
         <description>cancel an Invoice </description>
         <auto-attributes mode="IN" include="pk" optional="false"/>
</service>

The invoke name is clear for you ?
If yes, I can improve my code :)

Nicolas
Reply | Threaded
Open this post in threaded view
|

Re: entity-auto and cancel operation

Jacques Le Roux
Administrator
Le 12/02/2016 08:28, Nicolas Malin a écrit :

> Le 11/02/2016 22:51, Jacques Le Roux a écrit :
>>>>>  * 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?
> If you call a service like that :
>
> <service name="cancelInvoice" engine="entity-auto" default-entity-name="Invoice" invoke="expire" auth="true">
>         <description>cancel an Invoice </description>
>         <auto-attributes mode="IN" include="pk" optional="false"/>
> </service>
>
> The invoke name is clear for you ?
> If yes, I can improve my code :)

If you mean that it implies it will set the INVOICE_CANCELLED status then yes :)

Thanks

Jacques

>
> Nicolas
>
Reply | Threaded
Open this post in threaded view
|

Re: entity-auto and cancel operation

Nicolas Malin-2
Le 12/02/2016 11:36, Jacques Le Roux a écrit :

>>>
>>> You will manage it later?
>> If you call a service like that :
>>
>> <service name="cancelInvoice" engine="entity-auto"
>> default-entity-name="Invoice" invoke="expire" auth="true">
>>         <description>cancel an Invoice </description>
>>         <auto-attributes mode="IN" include="pk" optional="false"/>
>> </service>
>>
>> The invoke name is clear for you ?
>> If yes, I can improve my code :)
>
> If you mean that it implies it will set the INVOICE_CANCELLED status
> then yes :)
Ok good response :)

I propose first to validate the process with field date to expire and
after manage the status.

Nicolas
Reply | Threaded
Open this post in threaded view
|

Re: entity-auto and cancel operation

Jacques Le Roux
Administrator
Le 12/02/2016 22:57, Nicolas Malin a écrit :

> Le 12/02/2016 11:36, Jacques Le Roux a écrit :
>>>>
>>>> You will manage it later?
>>> If you call a service like that :
>>>
>>> <service name="cancelInvoice" engine="entity-auto" default-entity-name="Invoice" invoke="expire" auth="true">
>>>         <description>cancel an Invoice </description>
>>>         <auto-attributes mode="IN" include="pk" optional="false"/>
>>> </service>
>>>
>>> The invoke name is clear for you ?
>>> If yes, I can improve my code :)
>>
>> If you mean that it implies it will set the INVOICE_CANCELLED status then yes :)
> Ok good response :)
>
> I propose first to validate the process with field date to expire and after manage the status.
>
> Nicolas
>
+1

Jacques