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 :) |
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,
|
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 :) > |
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/ |
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/ > |
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 |
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. |
'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. >> > > |
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. >>> >> |
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 > > 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 > |
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. >>>> >>> |
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 >> > |
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? <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 |
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 > |
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 :) I propose first to validate the process with field date to expire and after manage the status. Nicolas |
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 > Jacques |
Free forum by Nabble | Edit this page |