Re: why some fields are set to enable-audit-log true by default?

[Jacques Le Roux]

Hi,

Moving this discussion from user ML

I agree Nicolas, I see no reasons to OOTB enable audit log in any of the fields which currently supports it. Not sure if we need to go with extending
entities.

Note: the only entities concerned are OrderItem, OrderItemShipGroup, ReturnItem

Jacques


Le 03/04/2018 à 23:33, Nicolas Malin a écrit :

> Hello,
>
> There is a good example on issue OFBIZ-2483 [1]. Personally, I'm not in favor to enable audit log in framework code base because impact the
> performance. I suggest to convert all current activation to disable, prepare some entity field with extend-entity that contains entity-audit-log on
> the related component and inform on screen who used this table how enable the audit log.
>
> But for that it's I also suggest to move the discussion to dev ;)
>
> Nicolas
>
> [1] https://issues.apache.org/jira/browse/OFBIZ-2483 Add History Function to Returns so we can see who Created, Edited, Completed return
>
> On 03/04/2018 21:57, pierre.gaudin wrote:
>> Hi all,
>>
>> In the definition of some entities, certain fields are set to enable-audit-log = true by default.
>>
>> Is there a reason for that?
>>
>>
>> thanks,
>>
>>
>> pierre
>>
>
>

[pierre.gaudin]

Hi,

Thanks Nicolas to point to this issue.

I also think that this attribute should be used only for technical
purpose, not for functional purposes.


Pierre

On 04/04/2018 08:54, Jacques Le Roux wrote:

> Hi,
>
> Moving this discussion from user ML
>
> I agree Nicolas, I see no reasons to OOTB enable audit log in any of
> the fields which currently supports it. Not sure if we need to go with
> extending entities.
>
> Note: the only entities concerned are OrderItem, OrderItemShipGroup,
> ReturnItem
>
> Jacques
>
>
> Le 03/04/2018 à 23:33, Nicolas Malin a écrit :
>> Hello,
>>
>> There is a good example on issue OFBIZ-2483 [1]. Personally, I'm not
>> in favor to enable audit log in framework code base because impact
>> the performance. I suggest to convert all current activation to
>> disable, prepare some entity field with extend-entity that contains
>> entity-audit-log on the related component and inform on screen who
>> used this table how enable the audit log.
>>
>> But for that it's I also suggest to move the discussion to dev ;)
>>
>> Nicolas
>>
>> [1] https://issues.apache.org/jira/browse/OFBIZ-2483 Add History
>> Function to Returns so we can see who Created, Edited, Completed return
>>
>> On 03/04/2018 21:57, pierre.gaudin wrote:
>>> Hi all,
>>>
>>> In the definition of some entities, certain fields are set to
>>> enable-audit-log = true by default.
>>>
>>> Is there a reason for that?
>>>
>>>
>>> thanks,
>>>
>>>
>>> pierre
>>>
>>
>>
>
>

[taher]

+1 to their removal. A quick grep lists the fields which have that
flag. I'm not sure about the field in the entity component though! it
might be needed in some unit tests?

framework/entity/entitydef/entitymodel_test.xml:        <field
name="testingName" type="name" enable-audit-log="true"/>
applications/datamodel/entitydef/order-entitymodel.xml:      <field
name="quantity" type="fixed-point" enable-audit-log="true"></field>
applications/datamodel/entitydef/order-entitymodel.xml:      <field
name="unitPrice" type="currency-precise"
enable-audit-log="true"></field>
applications/datamodel/entitydef/order-entitymodel.xml:      <field
name="changeByUserLoginId" type="id-vlong"
enable-audit-log="true"></field>
applications/datamodel/entitydef/order-entitymodel.xml:      <field
name="shipmentMethodTypeId" type="id" enable-audit-log="true"></field>
applications/datamodel/entitydef/order-entitymodel.xml:      <field
name="carrierPartyId" type="id" enable-audit-log="true"></field>
applications/datamodel/entitydef/order-entitymodel.xml:        <field
name="returnReasonId" type="id" enable-audit-log="true">
applications/datamodel/entitydef/order-entitymodel.xml:        <field
name="returnTypeId" type="id" enable-audit-log="true">
applications/datamodel/entitydef/order-entitymodel.xml:        <field
name="returnQuantity" type="fixed-point"
enable-audit-log="true"><description>promised by the
customer</description></field>
applications/datamodel/entitydef/order-entitymodel.xml:        <field
name="receivedQuantity" type="fixed-point"
enable-audit-log="true"><description>actually received from the
customer</description></field>
applications/datamodel/entitydef/order-entitymodel.xml:        <field
name="returnPrice" type="currency-amount"
enable-audit-log="true"></field>

On Wed, Apr 4, 2018 at 10:57 AM, pierre.gaudin <[hidden email]> wrote:

> Hi,
>
> Thanks Nicolas to point to this issue.
>
> I also think that this attribute should be used only for technical purpose,
> not for functional purposes.
>
>
> Pierre
>
>
> On 04/04/2018 08:54, Jacques Le Roux wrote:
>>
>> Hi,
>>
>> Moving this discussion from user ML
>>
>> I agree Nicolas, I see no reasons to OOTB enable audit log in any of the
>> fields which currently supports it. Not sure if we need to go with extending
>> entities.
>>
>> Note: the only entities concerned are OrderItem, OrderItemShipGroup,
>> ReturnItem
>>
>> Jacques
>>
>>
>> Le 03/04/2018 à 23:33, Nicolas Malin a écrit :
>>>
>>> Hello,
>>>
>>> There is a good example on issue OFBIZ-2483 [1]. Personally, I'm not in
>>> favor to enable audit log in framework code base because impact the
>>> performance. I suggest to convert all current activation to disable, prepare
>>> some entity field with extend-entity that contains entity-audit-log on the
>>> related component and inform on screen who used this table how enable the
>>> audit log.
>>>
>>> But for that it's I also suggest to move the discussion to dev ;)
>>>
>>> Nicolas
>>>
>>> [1] https://issues.apache.org/jira/browse/OFBIZ-2483 Add History Function
>>> to Returns so we can see who Created, Edited, Completed return
>>>
>>> On 03/04/2018 21:57, pierre.gaudin wrote:
>>>>
>>>> Hi all,
>>>>
>>>> In the definition of some entities, certain fields are set to
>>>> enable-audit-log = true by default.
>>>>
>>>> Is there a reason for that?
>>>>
>>>>
>>>> thanks,
>>>>
>>>>
>>>> pierre
>>>>
>>>
>>>
>>
>>
>

[Jacques Le Roux]

Le 04/04/2018 à 12:07, Taher Alkhateeb a écrit :
> I'm not sure about the field in the entity component though! it
> might be needed in some unit tests?
Yes

Jacques

[Scott Gray-3]

It would be good to leave it on somewhere in the system like the example
entities maybe

On Wed, 4 Apr 2018, 22:13 Jacques Le Roux, <[hidden email]>
wrote:

> Le 04/04/2018 à 12:07, Taher Alkhateeb a écrit :
> > I'm not sure about the field in the entity component though! it
> > might be needed in some unit tests?
> Yes
>
> Jacques
>
>

[Rishi Solanki]

+1 for removal.
+1 to Scott for having an example in the system ... Example entities seems
right place as mentioned.

Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: [phone]
http://www.hotwaxsystems.com
www.hotwax.co

On Thu, Apr 5, 2018 at 5:38 AM, Scott Gray <[hidden email]>
wrote:

> It would be good to leave it on somewhere in the system like the example
> entities maybe
>
> On Wed, 4 Apr 2018, 22:13 Jacques Le Roux, <[hidden email]>
> wrote:
>
> > Le 04/04/2018 à 12:07, Taher Alkhateeb a écrit :
> > > I'm not sure about the field in the entity component though! it
> > > might be needed in some unit tests?
> > Yes
> >
> > Jacques
> >
> >
>

[Jacques Le Roux]

I'm not sure about Example component, it's now a plugin...

Maybe having an example in Entity component for the test is enough?

Also there is the auto-completion from XSD

But anyway not against Example component

Jacques


Le 05/04/2018 à 11:36, Rishi Solanki a écrit :

> +1 for removal.
> +1 to Scott for having an example in the system ... Example entities seems
> right place as mentioned.
>
> Rishi Solanki
> Sr Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: [phone]
> http://www.hotwaxsystems.com
> www.hotwax.co
>
> On Thu, Apr 5, 2018 at 5:38 AM, Scott Gray <[hidden email]>
> wrote:
>
>> It would be good to leave it on somewhere in the system like the example
>> entities maybe
>>
>> On Wed, 4 Apr 2018, 22:13 Jacques Le Roux, <[hidden email]>
>> wrote:
>>
>>> Le 04/04/2018 à 12:07, Taher Alkhateeb a écrit :
>>>> I'm not sure about the field in the entity component though! it
>>>> might be needed in some unit tests?
>>> Yes
>>>
>>> Jacques
>>>
>>>

[taher]

Hmm, I see no problem in example being a plugin. Just because it's a
plugin doesn't mean it lost its value or purpose (to give people
examples). So sounds good by me to add such fields to the example
component.

In fact, I would suggest that not only add them, but show the users
how to view the results from that audit log. And on the long term,
this could probably go to the developer documentation manual under the
entity engine section.

On Thu, Apr 5, 2018 at 12:44 PM, Jacques Le Roux
<[hidden email]> wrote:

> I'm not sure about Example component, it's now a plugin...
>
> Maybe having an example in Entity component for the test is enough?
>
> Also there is the auto-completion from XSD
>
> But anyway not against Example component
>
> Jacques
>
>
>
> Le 05/04/2018 à 11:36, Rishi Solanki a écrit :
>>
>> +1 for removal.
>> +1 to Scott for having an example in the system ... Example entities seems
>> right place as mentioned.
>>
>> Rishi Solanki
>> Sr Manager, Enterprise Software Development
>> HotWax Systems Pvt. Ltd.
>> Direct: [phone]
>> http://www.hotwaxsystems.com
>> www.hotwax.co
>>
>> On Thu, Apr 5, 2018 at 5:38 AM, Scott Gray <[hidden email]>
>> wrote:
>>
>>> It would be good to leave it on somewhere in the system like the example
>>> entities maybe
>>>
>>> On Wed, 4 Apr 2018, 22:13 Jacques Le Roux, <[hidden email]>
>>> wrote:
>>>
>>>> Le 04/04/2018 à 12:07, Taher Alkhateeb a écrit :
>>>>>
>>>>> I'm not sure about the field in the entity component though! it
>>>>> might be needed in some unit tests?
>>>>
>>>> Yes
>>>>
>>>> Jacques
>>>>
>>>>
>

[Jacques Le Roux]

Le 05/04/2018 à 11:49, Taher Alkhateeb a écrit :
> Hmm, I see no problem in example being a plugin. Just because it's a
> plugin doesn't mean it lost its value or purpose (to give people
> examples). So sounds good by me to add such fields to the example
> component.
Just that people using OFBiz without the example plugin will not be aware of this feature by this addition.

Jacques

[Jacques Le Roux]

Le 05/04/2018 à 13:25, Jacques Le Roux a écrit :

> Le 05/04/2018 à 11:49, Taher Alkhateeb a écrit :
>> Hmm, I see no problem in example being a plugin. Just because it's a
>> plugin doesn't mean it lost its value or purpose (to give people
>> examples). So sounds good by me to add such fields to the example
>> component.
> Just that people using OFBiz without the example plugin will not be aware of this feature by this addition.
>
> Jacques
>
>

BTW, just thinking about it, maybe we should recommend in documentation to load at least the example plugin when starting with OFBiz.

Jacques