Re: entity-auto and cancel operation

[Jacques Le Roux]

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 :


cancel an Invoice 



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

Re: entity-auto and cancel operation

[Nicolas Malin]

Le 12/02/2016 11:36, Jacques Le Roux a écrit :


You will manage it later? 

If you call a service like that :

default-entity-name="Invoice" invoke="expire" auth="true">

cancel an Invoice 



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

Re: entity-auto and cancel operation

[Jacques Le Roux]

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 :


cancel an Invoice 



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

Re: entity-auto and cancel operation

[Nicolas Malin]

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 :

default-entity-name="Invoice" invoke="expire" auth="true">

cancel an Invoice 



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

Nicolas

Re: entity-auto and cancel operation

[Jacques Le Roux]

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

complete the time associate to a task





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.

h yes it's true



if one case match, call update

After we would be use the pattern like cancelProductCategoryMember.


Cancel a ProductCategoryMember




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?
-
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

Re: entity-auto and cancel operation

[Nicolas Malin]

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 


wrote:


+1


Le 06/02/2016 20:54, Pierre Smits a écrit :


What about 'expire'? Seems also appropriate.

Re: entity-auto and cancel operation

[Nicolas Malin]

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


+1


Le 06/02/2016 20:54, Pierre Smits a écrit :


What about 'expire'? Seems also appropriate.

Re: entity-auto and cancel operation

[Nicolas Malin]

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) :
default-entity-name="WorkEffort" invoke="expire" auth="true">

complete the time associate to a task

mode="IN" optional="true"/>





 * 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.

h yes it's true



if one case match, call update

After we would be use the pattern like cancelProductCategoryMember.

default-entity-name="ProductCategoryMember" invoke="cancel" auth="true">

Cancel a ProductCategoryMember
main-action="UPDATE"/>




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?
-
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

Re: entity-auto and cancel operation

[Deepak Dixit]

'expire' sounds good.

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

On Sun, Feb 7, 2016 at 8:12 PM, Julien NICOLAS 
wrote:

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

Re: entity-auto and cancel operation

[Julien NICOLAS]

+1

Le 06/02/2016 20:54, Pierre Smits a écrit :

What about 'expire'? Seems also appropriate.

Re: entity-auto and cancel operation

[Jacques Le Roux]

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.


Cancel a ProductCategoryMember




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?
-
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

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"  wrote:

> What about 'expire'? Seems also appropriate.
>
> Best regards,
>
> Pierre
>
> Op zaterdag 6 februari 2016 heeft Julien NICOLAS <
> julien.nico...@nereide.fr>
> 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.
> >>>
> >>>  >>> default-entity-name="ProductCategoryMember" invoke="cancel"
> auth="true">
> >>> Cancel a ProductCategoryMember
> >>>  >>> main-action="UPDATE"/>
> >>> 
> >>> 
> >>>
> >>> As usual any suggest are welcome :)
> >>>
> >>
> >>
> >
>
> --
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>

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 
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.
>>>
>>> >> default-entity-name="ProductCategoryMember" invoke="cancel" auth="true">
>>> Cancel a ProductCategoryMember
>>> >> main-action="UPDATE"/>
>>> 
>>> 
>>>
>>> As usual any suggest are welcome :)
>>>
>>
>>
>

-- 
Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

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.

default-entity-name="ProductCategoryMember" invoke="cancel" auth="true">

Cancel a ProductCategoryMember
main-action="UPDATE"/>




As usual any suggest are welcome :)

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.

default-entity-name="ProductCategoryMember" invoke="cancel" auth="true">

Cancel a ProductCategoryMember
main-action="UPDATE"/>




As usual any suggest are welcome :)