[PROPOSAL] DataModel - Improve Internal Fields injection

[Pierre Smits-3]

Hi All,

Currently our functions inject following internal fields into the model of
each entity:

   - createdStamp
   - createdTxStamp
   - lastUpdatedStamp
   - lastUpdatedTxStamp

All of the fields above are of the field type definition 'date-time',
giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This means
that the createdTxStamp is the same as createdStamp  and lastUpdatedTxStamp
is the same as lastUpdatedStamp.

Should we get rid of the redundant fields?

Also, a lot of entity definitions in the various models have the
'createdByUserLogin' and 'lastModifiedByUserLogin' added.

Should we have these fields added to the internal fields set so that these
are always injected into the model of each entity, and always filled?

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer

[Rishi Solanki]

Dear Pierre,
I'm not aware of history of this duplicate entries. I agree with you on
removing duplicate fields. Also agree with adding created user and updated
user fields as default.

Few points for open discussion for community;
- There are many entities already have user fields, so do we need to remove
them. Point to discuss. IMO we can live with both.
- There are certain entries like dimension, search etc which does not
require user information.
- From community if someone have information on Tx fields then we can
rethink of not removing.

Lastly, this thread should take time to conclude after all inputs.

Thanks for interesting proposal!

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems <http://www.hotwaxsystems.com/>
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P 452010
Linkedin: *Rishi Solanki*
<https://www.linkedin.com/in/rishi-solanki-62271b7/>
Direct: [phone]


On Wed, Apr 24, 2019 at 1:19 PM Pierre Smits <[hidden email]> wrote:

> Hi All,
>
> Currently our functions inject following internal fields into the model of
> each entity:
>
>    - createdStamp
>    - createdTxStamp
>    - lastUpdatedStamp
>    - lastUpdatedTxStamp
>
> All of the fields above are of the field type definition 'date-time',
> giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This means
> that the createdTxStamp is the same as createdStamp  and lastUpdatedTxStamp
> is the same as lastUpdatedStamp.
>
> Should we get rid of the redundant fields?
>
> Also, a lot of entity definitions in the various models have the
> 'createdByUserLogin' and 'lastModifiedByUserLogin' added.
>
> Should we have these fields added to the internal fields set so that these
> are always injected into the model of each entity, and always filled?
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
> since 2008*
> Apache Steve <https://steve.apache.org>, committer
>

[Michael Brohl-3]

These fields are not the same, they can differ. The TX fields mark the
transaction timestamp while the non TX fields mark the "real" update
time. You can see it when you watch closely in the database. All changes
made within an transaction have the same tx timestamp.

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 24.04.19 um 09:48 schrieb Pierre Smits:

> Hi All,
>
> Currently our functions inject following internal fields into the model of
> each entity:
>
>     - createdStamp
>     - createdTxStamp
>     - lastUpdatedStamp
>     - lastUpdatedTxStamp
>
> All of the fields above are of the field type definition 'date-time',
> giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This means
> that the createdTxStamp is the same as createdStamp  and lastUpdatedTxStamp
> is the same as lastUpdatedStamp.
>
> Should we get rid of the redundant fields?
>
> Also, a lot of entity definitions in the various models have the
> 'createdByUserLogin' and 'lastModifiedByUserLogin' added.
>
> Should we have these fields added to the internal fields set so that these
> are always injected into the model of each entity, and always filled?
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
> since 2008*
> Apache Steve <https://steve.apache.org>, committer
>

[Pierre Smits-3]

Thanks Michael,

So we should keep those *TxStamp fields.

But what about the second suggestion about having the  'createdByUserLogin'
and 'lastModifiedByUserLogin'  fields added to the internal fields set?

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Wed, Apr 24, 2019 at 12:20 PM Michael Brohl <[hidden email]>
wrote:

> These fields are not the same, they can differ. The TX fields mark the
> transaction timestamp while the non TX fields mark the "real" update
> time. You can see it when you watch closely in the database. All changes
> made within an transaction have the same tx timestamp.
>
> Regards,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 24.04.19 um 09:48 schrieb Pierre Smits:
> > Hi All,
> >
> > Currently our functions inject following internal fields into the model
> of
> > each entity:
> >
> >     - createdStamp
> >     - createdTxStamp
> >     - lastUpdatedStamp
> >     - lastUpdatedTxStamp
> >
> > All of the fields above are of the field type definition 'date-time',
> > giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This means
> > that the createdTxStamp is the same as createdStamp  and
> lastUpdatedTxStamp
> > is the same as lastUpdatedStamp.
> >
> > Should we get rid of the redundant fields?
> >
> > Also, a lot of entity definitions in the various models have the
> > 'createdByUserLogin' and 'lastModifiedByUserLogin' added.
> >
> > Should we have these fields added to the internal fields set so that
> these
> > are always injected into the model of each entity, and always filled?
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> privileges)
> > since 2008*
> > Apache Steve <https://steve.apache.org>, committer
> >
>
>

[Michael Brohl-3]

I have not time to elaborate in-depth right now, but just a quick food
for thought:

Having these fields in every entity *by default* allows detailed
tracking of users which might be unwanted. I know that this is a
sensible topic in companies and affects privacy protection.

I am not sure how the selection of entities with these fields was done,
maybe others can add insights.

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 24.04.19 um 12:40 schrieb Pierre Smits:

> Thanks Michael,
>
> So we should keep those *TxStamp fields.
>
> But what about the second suggestion about having the  'createdByUserLogin'
> and 'lastModifiedByUserLogin'  fields added to the internal fields set?
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
> since 2008*
> Apache Steve <https://steve.apache.org>, committer
>
>
> On Wed, Apr 24, 2019 at 12:20 PM Michael Brohl <[hidden email]>
> wrote:
>
>> These fields are not the same, they can differ. The TX fields mark the
>> transaction timestamp while the non TX fields mark the "real" update
>> time. You can see it when you watch closely in the database. All changes
>> made within an transaction have the same tx timestamp.
>>
>> Regards,
>>
>> Michael Brohl
>>
>> ecomify GmbH - www.ecomify.de
>>
>>
>> Am 24.04.19 um 09:48 schrieb Pierre Smits:
>>> Hi All,
>>>
>>> Currently our functions inject following internal fields into the model
>> of
>>> each entity:
>>>
>>>      - createdStamp
>>>      - createdTxStamp
>>>      - lastUpdatedStamp
>>>      - lastUpdatedTxStamp
>>>
>>> All of the fields above are of the field type definition 'date-time',
>>> giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This means
>>> that the createdTxStamp is the same as createdStamp  and
>> lastUpdatedTxStamp
>>> is the same as lastUpdatedStamp.
>>>
>>> Should we get rid of the redundant fields?
>>>
>>> Also, a lot of entity definitions in the various models have the
>>> 'createdByUserLogin' and 'lastModifiedByUserLogin' added.
>>>
>>> Should we have these fields added to the internal fields set so that
>> these
>>> are always injected into the model of each entity, and always filled?
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
>>> *Apache Directory <https://directory.apache.org>, PMC Member*
>>> Apache Incubator <https://incubator.apache.org>, committer
>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
>> privileges)
>>> since 2008*
>>> Apache Steve <https://steve.apache.org>, committer
>>>
>>

[Deepak Dixit-4]

I am not able to find the thread,
But I remember we had already a discussion regarding the same topic.

Kind Regards,
Deepak Dixit


On Wed, Apr 24, 2019 at 4:37 PM Michael Brohl <[hidden email]>
wrote:

> I have not time to elaborate in-depth right now, but just a quick food
> for thought:
>
> Having these fields in every entity *by default* allows detailed
> tracking of users which might be unwanted. I know that this is a
> sensible topic in companies and affects privacy protection.
>
> I am not sure how the selection of entities with these fields was done,
> maybe others can add insights.
>
> Regards,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 24.04.19 um 12:40 schrieb Pierre Smits:
> > Thanks Michael,
> >
> > So we should keep those *TxStamp fields.
> >
> > But what about the second suggestion about having the
> 'createdByUserLogin'
> > and 'lastModifiedByUserLogin'  fields added to the internal fields set?
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> privileges)
> > since 2008*
> > Apache Steve <https://steve.apache.org>, committer
> >
> >
> > On Wed, Apr 24, 2019 at 12:20 PM Michael Brohl <[hidden email]
> >
> > wrote:
> >
> >> These fields are not the same, they can differ. The TX fields mark the
> >> transaction timestamp while the non TX fields mark the "real" update
> >> time. You can see it when you watch closely in the database. All changes
> >> made within an transaction have the same tx timestamp.
> >>
> >> Regards,
> >>
> >> Michael Brohl
> >>
> >> ecomify GmbH - www.ecomify.de
> >>
> >>
> >> Am 24.04.19 um 09:48 schrieb Pierre Smits:
> >>> Hi All,
> >>>
> >>> Currently our functions inject following internal fields into the model
> >> of
> >>> each entity:
> >>>
> >>>      - createdStamp
> >>>      - createdTxStamp
> >>>      - lastUpdatedStamp
> >>>      - lastUpdatedTxStamp
> >>>
> >>> All of the fields above are of the field type definition 'date-time',
> >>> giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This means
> >>> that the createdTxStamp is the same as createdStamp  and
> >> lastUpdatedTxStamp
> >>> is the same as lastUpdatedStamp.
> >>>
> >>> Should we get rid of the redundant fields?
> >>>
> >>> Also, a lot of entity definitions in the various models have the
> >>> 'createdByUserLogin' and 'lastModifiedByUserLogin' added.
> >>>
> >>> Should we have these fields added to the internal fields set so that
> >> these
> >>> are always injected into the model of each entity, and always filled?
> >>>
> >>> Best regards,
> >>>
> >>> Pierre Smits
> >>>
> >>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> >>> *Apache Directory <https://directory.apache.org>, PMC Member*
> >>> Apache Incubator <https://incubator.apache.org>, committer
> >>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> >> privileges)
> >>> since 2008*
> >>> Apache Steve <https://steve.apache.org>, committer
> >>>
> >>
>
>

[Rishi Solanki]

Michael,
Thank you for details, all makes sense.

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems <http://www.hotwaxsystems.com/>
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P 452010
Linkedin: *Rishi Solanki*
<https://www.linkedin.com/in/rishi-solanki-62271b7/>
Direct: [phone]


On Wed, Apr 24, 2019 at 4:37 PM Michael Brohl <[hidden email]>
wrote:

> I have not time to elaborate in-depth right now, but just a quick food
> for thought:
>
> Having these fields in every entity *by default* allows detailed
> tracking of users which might be unwanted. I know that this is a
> sensible topic in companies and affects privacy protection.
>
> I am not sure how the selection of entities with these fields was done,
> maybe others can add insights.
>
> Regards,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 24.04.19 um 12:40 schrieb Pierre Smits:
> > Thanks Michael,
> >
> > So we should keep those *TxStamp fields.
> >
> > But what about the second suggestion about having the
> 'createdByUserLogin'
> > and 'lastModifiedByUserLogin'  fields added to the internal fields set?
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> privileges)
> > since 2008*
> > Apache Steve <https://steve.apache.org>, committer
> >
> >
> > On Wed, Apr 24, 2019 at 12:20 PM Michael Brohl <[hidden email]
> >
> > wrote:
> >
> >> These fields are not the same, they can differ. The TX fields mark the
> >> transaction timestamp while the non TX fields mark the "real" update
> >> time. You can see it when you watch closely in the database. All changes
> >> made within an transaction have the same tx timestamp.
> >>
> >> Regards,
> >>
> >> Michael Brohl
> >>
> >> ecomify GmbH - www.ecomify.de
> >>
> >>
> >> Am 24.04.19 um 09:48 schrieb Pierre Smits:
> >>> Hi All,
> >>>
> >>> Currently our functions inject following internal fields into the model
> >> of
> >>> each entity:
> >>>
> >>>      - createdStamp
> >>>      - createdTxStamp
> >>>      - lastUpdatedStamp
> >>>      - lastUpdatedTxStamp
> >>>
> >>> All of the fields above are of the field type definition 'date-time',
> >>> giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This means
> >>> that the createdTxStamp is the same as createdStamp  and
> >> lastUpdatedTxStamp
> >>> is the same as lastUpdatedStamp.
> >>>
> >>> Should we get rid of the redundant fields?
> >>>
> >>> Also, a lot of entity definitions in the various models have the
> >>> 'createdByUserLogin' and 'lastModifiedByUserLogin' added.
> >>>
> >>> Should we have these fields added to the internal fields set so that
> >> these
> >>> are always injected into the model of each entity, and always filled?
> >>>
> >>> Best regards,
> >>>
> >>> Pierre Smits
> >>>
> >>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> >>> *Apache Directory <https://directory.apache.org>, PMC Member*
> >>> Apache Incubator <https://incubator.apache.org>, committer
> >>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> >> privileges)
> >>> since 2008*
> >>> Apache Steve <https://steve.apache.org>, committer
> >>>
> >>
>
>

[Jacques Le Roux]

A bit out of subject, just to complete the discussion because nobody spoke about.

The entities are defined with no-auto-stamp="false" by default so it's possible to change this default.

Of course 'createdByUserLogin' and 'lastModifiedByUserLogin' fields are not concerned, it was just to complete

Jacques


Le 24/04/2019 à 13:36, Rishi Solanki a écrit :

> Michael,
> Thank you for details, all makes sense.
>
> Best Regards,
> --
> *Rishi Solanki* | Sr Manager, Enterprise Software Development
> HotWax Systems <http://www.hotwaxsystems.com/>
> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
> M.P 452010
> Linkedin: *Rishi Solanki*
> <https://www.linkedin.com/in/rishi-solanki-62271b7/>
> Direct: [phone]
>
>
> On Wed, Apr 24, 2019 at 4:37 PM Michael Brohl <[hidden email]>
> wrote:
>
>> I have not time to elaborate in-depth right now, but just a quick food
>> for thought:
>>
>> Having these fields in every entity *by default* allows detailed
>> tracking of users which might be unwanted. I know that this is a
>> sensible topic in companies and affects privacy protection.
>>
>> I am not sure how the selection of entities with these fields was done,
>> maybe others can add insights.
>>
>> Regards,
>>
>> Michael Brohl
>>
>> ecomify GmbH - www.ecomify.de
>>
>>
>> Am 24.04.19 um 12:40 schrieb Pierre Smits:
>>> Thanks Michael,
>>>
>>> So we should keep those *TxStamp fields.
>>>
>>> But what about the second suggestion about having the
>> 'createdByUserLogin'
>>> and 'lastModifiedByUserLogin'  fields added to the internal fields set?
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
>>> *Apache Directory <https://directory.apache.org>, PMC Member*
>>> Apache Incubator <https://incubator.apache.org>, committer
>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
>> privileges)
>>> since 2008*
>>> Apache Steve <https://steve.apache.org>, committer
>>>
>>>
>>> On Wed, Apr 24, 2019 at 12:20 PM Michael Brohl <[hidden email]
>>>
>>> wrote:
>>>
>>>> These fields are not the same, they can differ. The TX fields mark the
>>>> transaction timestamp while the non TX fields mark the "real" update
>>>> time. You can see it when you watch closely in the database. All changes
>>>> made within an transaction have the same tx timestamp.
>>>>
>>>> Regards,
>>>>
>>>> Michael Brohl
>>>>
>>>> ecomify GmbH - www.ecomify.de
>>>>
>>>>
>>>> Am 24.04.19 um 09:48 schrieb Pierre Smits:
>>>>> Hi All,
>>>>>
>>>>> Currently our functions inject following internal fields into the model
>>>> of
>>>>> each entity:
>>>>>
>>>>>       - createdStamp
>>>>>       - createdTxStamp
>>>>>       - lastUpdatedStamp
>>>>>       - lastUpdatedTxStamp
>>>>>
>>>>> All of the fields above are of the field type definition 'date-time',
>>>>> giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This means
>>>>> that the createdTxStamp is the same as createdStamp  and
>>>> lastUpdatedTxStamp
>>>>> is the same as lastUpdatedStamp.
>>>>>
>>>>> Should we get rid of the redundant fields?
>>>>>
>>>>> Also, a lot of entity definitions in the various models have the
>>>>> 'createdByUserLogin' and 'lastModifiedByUserLogin' added.
>>>>>
>>>>> Should we have these fields added to the internal fields set so that
>>>> these
>>>>> are always injected into the model of each entity, and always filled?
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Pierre Smits
>>>>>
>>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
>>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
>>>>> Apache Incubator <https://incubator.apache.org>, committer
>>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
>>>> privileges)
>>>>> since 2008*
>>>>> Apache Steve <https://steve.apache.org>, committer
>>>>>
>>

[Suraj Khurana-2]

IMO, this is configurable as Jacques pointed, so need to take any action.
In fact, I would suggest showing these fields while searching for any data
from entity-engine in webtools, because they are really helpful while
working in a dev environment for debugging.

Just my two cents !!!

--
Best Regards,
Suraj Khurana
TECHNICAL CONSULTANT
mobile: [phone]
email: [hidden email]
www.hotwax.co






On Wed, Apr 24, 2019 at 7:14 PM Jacques Le Roux <
[hidden email]> wrote:

> A bit out of subject, just to complete the discussion because nobody spoke
> about.
>
> The entities are defined with no-auto-stamp="false" by default so it's
> possible to change this default.
>
> Of course 'createdByUserLogin' and 'lastModifiedByUserLogin' fields are
> not concerned, it was just to complete
>
> Jacques
>
>
> Le 24/04/2019 à 13:36, Rishi Solanki a écrit :
> > Michael,
> > Thank you for details, all makes sense.
> >
> > Best Regards,
> > --
> > *Rishi Solanki* | Sr Manager, Enterprise Software Development
> > HotWax Systems <http://www.hotwaxsystems.com/>
> > Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> Indore,
> > M.P 452010
> > Linkedin: *Rishi Solanki*
> > <https://www.linkedin.com/in/rishi-solanki-62271b7/>
> > Direct: [phone]
> >
> >
> > On Wed, Apr 24, 2019 at 4:37 PM Michael Brohl <[hidden email]>
> > wrote:
> >
> >> I have not time to elaborate in-depth right now, but just a quick food
> >> for thought:
> >>
> >> Having these fields in every entity *by default* allows detailed
> >> tracking of users which might be unwanted. I know that this is a
> >> sensible topic in companies and affects privacy protection.
> >>
> >> I am not sure how the selection of entities with these fields was done,
> >> maybe others can add insights.
> >>
> >> Regards,
> >>
> >> Michael Brohl
> >>
> >> ecomify GmbH - www.ecomify.de
> >>
> >>
> >> Am 24.04.19 um 12:40 schrieb Pierre Smits:
> >>> Thanks Michael,
> >>>
> >>> So we should keep those *TxStamp fields.
> >>>
> >>> But what about the second suggestion about having the
> >> 'createdByUserLogin'
> >>> and 'lastModifiedByUserLogin'  fields added to the internal fields set?
> >>>
> >>> Best regards,
> >>>
> >>> Pierre Smits
> >>>
> >>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> >>> *Apache Directory <https://directory.apache.org>, PMC Member*
> >>> Apache Incubator <https://incubator.apache.org>, committer
> >>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> >> privileges)
> >>> since 2008*
> >>> Apache Steve <https://steve.apache.org>, committer
> >>>
> >>>
> >>> On Wed, Apr 24, 2019 at 12:20 PM Michael Brohl <
> [hidden email]
> >>>
> >>> wrote:
> >>>
> >>>> These fields are not the same, they can differ. The TX fields mark the
> >>>> transaction timestamp while the non TX fields mark the "real" update
> >>>> time. You can see it when you watch closely in the database. All
> changes
> >>>> made within an transaction have the same tx timestamp.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Michael Brohl
> >>>>
> >>>> ecomify GmbH - www.ecomify.de
> >>>>
> >>>>
> >>>> Am 24.04.19 um 09:48 schrieb Pierre Smits:
> >>>>> Hi All,
> >>>>>
> >>>>> Currently our functions inject following internal fields into the
> model
> >>>> of
> >>>>> each entity:
> >>>>>
> >>>>>       - createdStamp
> >>>>>       - createdTxStamp
> >>>>>       - lastUpdatedStamp
> >>>>>       - lastUpdatedTxStamp
> >>>>>
> >>>>> All of the fields above are of the field type definition 'date-time',
> >>>>> giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This
> means
> >>>>> that the createdTxStamp is the same as createdStamp  and
> >>>> lastUpdatedTxStamp
> >>>>> is the same as lastUpdatedStamp.
> >>>>>
> >>>>> Should we get rid of the redundant fields?
> >>>>>
> >>>>> Also, a lot of entity definitions in the various models have the
> >>>>> 'createdByUserLogin' and 'lastModifiedByUserLogin' added.
> >>>>>
> >>>>> Should we have these fields added to the internal fields set so that
> >>>> these
> >>>>> are always injected into the model of each entity, and always filled?
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>> Pierre Smits
> >>>>>
> >>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> >>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
> >>>>> Apache Incubator <https://incubator.apache.org>, committer
> >>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> >>>> privileges)
> >>>>> since 2008*
> >>>>> Apache Steve <https://steve.apache.org>, committer
> >>>>>
> >>
>

[Jacques Le Roux]

Le 25/04/2019 à 14:17, Suraj Khurana a écrit :
> IMO, this is configurable as Jacques pointed, so need to take any action.
> In fact, I would suggest showing these fields while searching for any data
> from entity-engine in webtools, because they are really helpful while
> working in a dev environment for debugging.

This could be configurable indeed (less need in production for instance so default would be false)

Jacques

>
> Just my two cents !!!
>
> --
> Best Regards,
> Suraj Khurana
> TECHNICAL CONSULTANT
> mobile: [phone]
> email: [hidden email]
> www.hotwax.co
>
>
>
>
>
>
> On Wed, Apr 24, 2019 at 7:14 PM Jacques Le Roux <
> [hidden email]> wrote:
>
>> A bit out of subject, just to complete the discussion because nobody spoke
>> about.
>>
>> The entities are defined with no-auto-stamp="false" by default so it's
>> possible to change this default.
>>
>> Of course 'createdByUserLogin' and 'lastModifiedByUserLogin' fields are
>> not concerned, it was just to complete
>>
>> Jacques
>>
>>
>> Le 24/04/2019 à 13:36, Rishi Solanki a écrit :
>>> Michael,
>>> Thank you for details, all makes sense.
>>>
>>> Best Regards,
>>> --
>>> *Rishi Solanki* | Sr Manager, Enterprise Software Development
>>> HotWax Systems <http://www.hotwaxsystems.com/>
>>> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
>> Indore,
>>> M.P 452010
>>> Linkedin: *Rishi Solanki*
>>> <https://www.linkedin.com/in/rishi-solanki-62271b7/>
>>> Direct: [phone]
>>>
>>>
>>> On Wed, Apr 24, 2019 at 4:37 PM Michael Brohl <[hidden email]>
>>> wrote:
>>>
>>>> I have not time to elaborate in-depth right now, but just a quick food
>>>> for thought:
>>>>
>>>> Having these fields in every entity *by default* allows detailed
>>>> tracking of users which might be unwanted. I know that this is a
>>>> sensible topic in companies and affects privacy protection.
>>>>
>>>> I am not sure how the selection of entities with these fields was done,
>>>> maybe others can add insights.
>>>>
>>>> Regards,
>>>>
>>>> Michael Brohl
>>>>
>>>> ecomify GmbH - www.ecomify.de
>>>>
>>>>
>>>> Am 24.04.19 um 12:40 schrieb Pierre Smits:
>>>>> Thanks Michael,
>>>>>
>>>>> So we should keep those *TxStamp fields.
>>>>>
>>>>> But what about the second suggestion about having the
>>>> 'createdByUserLogin'
>>>>> and 'lastModifiedByUserLogin'  fields added to the internal fields set?
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Pierre Smits
>>>>>
>>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
>>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
>>>>> Apache Incubator <https://incubator.apache.org>, committer
>>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
>>>> privileges)
>>>>> since 2008*
>>>>> Apache Steve <https://steve.apache.org>, committer
>>>>>
>>>>>
>>>>> On Wed, Apr 24, 2019 at 12:20 PM Michael Brohl <
>> [hidden email]
>>>>> wrote:
>>>>>
>>>>>> These fields are not the same, they can differ. The TX fields mark the
>>>>>> transaction timestamp while the non TX fields mark the "real" update
>>>>>> time. You can see it when you watch closely in the database. All
>> changes
>>>>>> made within an transaction have the same tx timestamp.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Michael Brohl
>>>>>>
>>>>>> ecomify GmbH - www.ecomify.de
>>>>>>
>>>>>>
>>>>>> Am 24.04.19 um 09:48 schrieb Pierre Smits:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Currently our functions inject following internal fields into the
>> model
>>>>>> of
>>>>>>> each entity:
>>>>>>>
>>>>>>>        - createdStamp
>>>>>>>        - createdTxStamp
>>>>>>>        - lastUpdatedStamp
>>>>>>>        - lastUpdatedTxStamp
>>>>>>>
>>>>>>> All of the fields above are of the field type definition 'date-time',
>>>>>>> giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This
>> means
>>>>>>> that the createdTxStamp is the same as createdStamp  and
>>>>>> lastUpdatedTxStamp
>>>>>>> is the same as lastUpdatedStamp.
>>>>>>>
>>>>>>> Should we get rid of the redundant fields?
>>>>>>>
>>>>>>> Also, a lot of entity definitions in the various models have the
>>>>>>> 'createdByUserLogin' and 'lastModifiedByUserLogin' added.
>>>>>>>
>>>>>>> Should we have these fields added to the internal fields set so that
>>>>>> these
>>>>>>> are always injected into the model of each entity, and always filled?
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Pierre Smits
>>>>>>>
>>>>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
>>>>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
>>>>>>> Apache Incubator <https://incubator.apache.org>, committer
>>>>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
>>>>>> privileges)
>>>>>>> since 2008*
>>>>>>> Apache Steve <https://steve.apache.org>, committer
>>>>>>>

[Pritam Kute]

IMO, adding 'createdByUserLogin' and 'lastModifiedByUserLogin' fields to
every entity is not that useful. Like for example, if we consider the
"Visit" entity, I am not able to find any advantage of having these fields
in this entity. But, it should be added to some crucial entities like
OrderHeader, OrderItem, ProductPrice(which is already there) to track the
things like who dod the last price updates or order updates.

Kind Regards,
--
Pritam Kute


On Thu, Apr 25, 2019 at 6:10 PM Jacques Le Roux <
[hidden email]> wrote:

> Le 25/04/2019 à 14:17, Suraj Khurana a écrit :
> > IMO, this is configurable as Jacques pointed, so need to take any action.
> > In fact, I would suggest showing these fields while searching for any
> data
> > from entity-engine in webtools, because they are really helpful while
> > working in a dev environment for debugging.
>
> This could be configurable indeed (less need in production for instance so
> default would be false)
>
> Jacques
>
> >
> > Just my two cents !!!
> >
> > --
> > Best Regards,
> > Suraj Khurana
> > TECHNICAL CONSULTANT
> > mobile: [phone]
> > email: [hidden email]
> > www.hotwax.co
> >
> >
> >
> >
> >
> >
> > On Wed, Apr 24, 2019 at 7:14 PM Jacques Le Roux <
> > [hidden email]> wrote:
> >
> >> A bit out of subject, just to complete the discussion because nobody
> spoke
> >> about.
> >>
> >> The entities are defined with no-auto-stamp="false" by default so it's
> >> possible to change this default.
> >>
> >> Of course 'createdByUserLogin' and 'lastModifiedByUserLogin' fields are
> >> not concerned, it was just to complete
> >>
> >> Jacques
> >>
> >>
> >> Le 24/04/2019 à 13:36, Rishi Solanki a écrit :
> >>> Michael,
> >>> Thank you for details, all makes sense.
> >>>
> >>> Best Regards,
> >>> --
> >>> *Rishi Solanki* | Sr Manager, Enterprise Software Development
> >>> HotWax Systems <http://www.hotwaxsystems.com/>
> >>> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> >> Indore,
> >>> M.P 452010
> >>> Linkedin: *Rishi Solanki*
> >>> <https://www.linkedin.com/in/rishi-solanki-62271b7/>
> >>> Direct: [phone]
> >>>
> >>>
> >>> On Wed, Apr 24, 2019 at 4:37 PM Michael Brohl <
> [hidden email]>
> >>> wrote:
> >>>
> >>>> I have not time to elaborate in-depth right now, but just a quick food
> >>>> for thought:
> >>>>
> >>>> Having these fields in every entity *by default* allows detailed
> >>>> tracking of users which might be unwanted. I know that this is a
> >>>> sensible topic in companies and affects privacy protection.
> >>>>
> >>>> I am not sure how the selection of entities with these fields was
> done,
> >>>> maybe others can add insights.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Michael Brohl
> >>>>
> >>>> ecomify GmbH - www.ecomify.de
> >>>>
> >>>>
> >>>> Am 24.04.19 um 12:40 schrieb Pierre Smits:
> >>>>> Thanks Michael,
> >>>>>
> >>>>> So we should keep those *TxStamp fields.
> >>>>>
> >>>>> But what about the second suggestion about having the
> >>>> 'createdByUserLogin'
> >>>>> and 'lastModifiedByUserLogin'  fields added to the internal fields
> set?
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>> Pierre Smits
> >>>>>
> >>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> >>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
> >>>>> Apache Incubator <https://incubator.apache.org>, committer
> >>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> >>>> privileges)
> >>>>> since 2008*
> >>>>> Apache Steve <https://steve.apache.org>, committer
> >>>>>
> >>>>>
> >>>>> On Wed, Apr 24, 2019 at 12:20 PM Michael Brohl <
> >> [hidden email]
> >>>>> wrote:
> >>>>>
> >>>>>> These fields are not the same, they can differ. The TX fields mark
> the
> >>>>>> transaction timestamp while the non TX fields mark the "real" update
> >>>>>> time. You can see it when you watch closely in the database. All
> >> changes
> >>>>>> made within an transaction have the same tx timestamp.
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>> Michael Brohl
> >>>>>>
> >>>>>> ecomify GmbH - www.ecomify.de
> >>>>>>
> >>>>>>
> >>>>>> Am 24.04.19 um 09:48 schrieb Pierre Smits:
> >>>>>>> Hi All,
> >>>>>>>
> >>>>>>> Currently our functions inject following internal fields into the
> >> model
> >>>>>> of
> >>>>>>> each entity:
> >>>>>>>
> >>>>>>>        - createdStamp
> >>>>>>>        - createdTxStamp
> >>>>>>>        - lastUpdatedStamp
> >>>>>>>        - lastUpdatedTxStamp
> >>>>>>>
> >>>>>>> All of the fields above are of the field type definition
> 'date-time',
> >>>>>>> giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This
> >> means
> >>>>>>> that the createdTxStamp is the same as createdStamp  and
> >>>>>> lastUpdatedTxStamp
> >>>>>>> is the same as lastUpdatedStamp.
> >>>>>>>
> >>>>>>> Should we get rid of the redundant fields?
> >>>>>>>
> >>>>>>> Also, a lot of entity definitions in the various models have the
> >>>>>>> 'createdByUserLogin' and 'lastModifiedByUserLogin' added.
> >>>>>>>
> >>>>>>> Should we have these fields added to the internal fields set so
> that
> >>>>>> these
> >>>>>>> are always injected into the model of each entity, and always
> filled?
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>>
> >>>>>>> Pierre Smits
> >>>>>>>
> >>>>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> >>>>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
> >>>>>>> Apache Incubator <https://incubator.apache.org>, committer
> >>>>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> >>>>>> privileges)
> >>>>>>> since 2008*
> >>>>>>> Apache Steve <https://steve.apache.org>, committer
> >>>>>>>
>

[Nicolas Malin-2]

Hello,

When I worked on issue OFBIZ-5010, I have been imagine to use an other
parameter on entity definition like internal to generate these 4 fields
createdByUserLogin, lastModifiedByUserLogin, createdDate, lastModifiedDate.

example :

     <entity name="Product" track="true" ...>

but more with idea to extend it

      <extend-entity entity-name="Product" track="true" />

If we want to load it or change the current internal default value, I
suggest to improve entity group or entity package to received this
information. Like this we can easily define the value for a set of
entity instead define it one by one.

Nicolas

On 26/04/2019 09:00, Pritam Kute wrote:

> IMO, adding 'createdByUserLogin' and 'lastModifiedByUserLogin' fields to
> every entity is not that useful. Like for example, if we consider the
> "Visit" entity, I am not able to find any advantage of having these fields
> in this entity. But, it should be added to some crucial entities like
> OrderHeader, OrderItem, ProductPrice(which is already there) to track the
> things like who dod the last price updates or order updates.
>
> Kind Regards,
> --
> Pritam Kute
>
>
> On Thu, Apr 25, 2019 at 6:10 PM Jacques Le Roux <
> [hidden email]> wrote:
>
>> Le 25/04/2019 à 14:17, Suraj Khurana a écrit :
>>> IMO, this is configurable as Jacques pointed, so need to take any action.
>>> In fact, I would suggest showing these fields while searching for any
>> data
>>> from entity-engine in webtools, because they are really helpful while
>>> working in a dev environment for debugging.
>> This could be configurable indeed (less need in production for instance so
>> default would be false)
>>
>> Jacques
>>
>>> Just my two cents !!!
>>>
>>> --
>>> Best Regards,
>>> Suraj Khurana
>>> TECHNICAL CONSULTANT
>>> mobile: [phone]
>>> email: [hidden email]
>>> www.hotwax.co
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Apr 24, 2019 at 7:14 PM Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>>> A bit out of subject, just to complete the discussion because nobody
>> spoke
>>>> about.
>>>>
>>>> The entities are defined with no-auto-stamp="false" by default so it's
>>>> possible to change this default.
>>>>
>>>> Of course 'createdByUserLogin' and 'lastModifiedByUserLogin' fields are
>>>> not concerned, it was just to complete
>>>>
>>>> Jacques
>>>>
>>>>
>>>> Le 24/04/2019 à 13:36, Rishi Solanki a écrit :
>>>>> Michael,
>>>>> Thank you for details, all makes sense.
>>>>>
>>>>> Best Regards,
>>>>> --
>>>>> *Rishi Solanki* | Sr Manager, Enterprise Software Development
>>>>> HotWax Systems <http://www.hotwaxsystems.com/>
>>>>> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
>>>> Indore,
>>>>> M.P 452010
>>>>> Linkedin: *Rishi Solanki*
>>>>> <https://www.linkedin.com/in/rishi-solanki-62271b7/>
>>>>> Direct: [phone]
>>>>>
>>>>>
>>>>> On Wed, Apr 24, 2019 at 4:37 PM Michael Brohl <
>> [hidden email]>
>>>>> wrote:
>>>>>
>>>>>> I have not time to elaborate in-depth right now, but just a quick food
>>>>>> for thought:
>>>>>>
>>>>>> Having these fields in every entity *by default* allows detailed
>>>>>> tracking of users which might be unwanted. I know that this is a
>>>>>> sensible topic in companies and affects privacy protection.
>>>>>>
>>>>>> I am not sure how the selection of entities with these fields was
>> done,
>>>>>> maybe others can add insights.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Michael Brohl
>>>>>>
>>>>>> ecomify GmbH - www.ecomify.de
>>>>>>
>>>>>>
>>>>>> Am 24.04.19 um 12:40 schrieb Pierre Smits:
>>>>>>> Thanks Michael,
>>>>>>>
>>>>>>> So we should keep those *TxStamp fields.
>>>>>>>
>>>>>>> But what about the second suggestion about having the
>>>>>> 'createdByUserLogin'
>>>>>>> and 'lastModifiedByUserLogin'  fields added to the internal fields
>> set?
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Pierre Smits
>>>>>>>
>>>>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
>>>>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
>>>>>>> Apache Incubator <https://incubator.apache.org>, committer
>>>>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
>>>>>> privileges)
>>>>>>> since 2008*
>>>>>>> Apache Steve <https://steve.apache.org>, committer
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Apr 24, 2019 at 12:20 PM Michael Brohl <
>>>> [hidden email]
>>>>>>> wrote:
>>>>>>>
>>>>>>>> These fields are not the same, they can differ. The TX fields mark
>> the
>>>>>>>> transaction timestamp while the non TX fields mark the "real" update
>>>>>>>> time. You can see it when you watch closely in the database. All
>>>> changes
>>>>>>>> made within an transaction have the same tx timestamp.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Michael Brohl
>>>>>>>>
>>>>>>>> ecomify GmbH - www.ecomify.de
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 24.04.19 um 09:48 schrieb Pierre Smits:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Currently our functions inject following internal fields into the
>>>> model
>>>>>>>> of
>>>>>>>>> each entity:
>>>>>>>>>
>>>>>>>>>         - createdStamp
>>>>>>>>>         - createdTxStamp
>>>>>>>>>         - lastUpdatedStamp
>>>>>>>>>         - lastUpdatedTxStamp
>>>>>>>>>
>>>>>>>>> All of the fields above are of the field type definition
>> 'date-time',
>>>>>>>>> giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This
>>>> means
>>>>>>>>> that the createdTxStamp is the same as createdStamp  and
>>>>>>>> lastUpdatedTxStamp
>>>>>>>>> is the same as lastUpdatedStamp.
>>>>>>>>>
>>>>>>>>> Should we get rid of the redundant fields?
>>>>>>>>>
>>>>>>>>> Also, a lot of entity definitions in the various models have the
>>>>>>>>> 'createdByUserLogin' and 'lastModifiedByUserLogin' added.
>>>>>>>>>
>>>>>>>>> Should we have these fields added to the internal fields set so
>> that
>>>>>>>> these
>>>>>>>>> are always injected into the model of each entity, and always
>> filled?
>>>>>>>>> Best regards,
>>>>>>>>>
>>>>>>>>> Pierre Smits
>>>>>>>>>
>>>>>>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
>>>>>>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
>>>>>>>>> Apache Incubator <https://incubator.apache.org>, committer
>>>>>>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
>>>>>>>> privileges)
>>>>>>>>> since 2008*
>>>>>>>>> Apache Steve <https://steve.apache.org>, committer
>>>>>>>>>

[Pierre Smits-3]

The two fields are extremely useful (even indispensable) regarding auditing
and data analysis. Consider security assessments and fraud
detection/prevention.

In trunk, only 48 entities have those fields in following breakdown:
Component Model Entities Having UserLogin fields %
datamodel accounting 160 3 1,88%
datamodel content 64 7 10,94%
datamodel humanres 41 1 2,44%
datamodel manufacturing 7   0,00%
datamodel marketing 32 8 25,00%
datamodel order 106 10 9,43%
datamodel party 81 2 2,47%
datamodel product 168 11 6,55%
datamodel facility 38 4 10,53%
datamodel workeffort 40 1 2,50%
  In apps 737 47 6,38%
  in framework 98 1 1,02%
Total   835 48 5,75%

That means that for the majority of the entities (more than 90%) our
adopters (using the data models OOTB) have no way of telling who created a
record and who modified it last. And we are talking about entities
regarding invoices, payments, gl transaction entries, orders, quotes,
product definitions, inventory quantities and locations, receipts,
deliveries etc., all which contain business critical data.

But also, with the recently feature regarding impersonation added to our
code base which allow other users to change records through OFBiz having
those two fields on each entity becomes business critical.

IMO the OFBiz should have these two fields established on each entity OOTB.

Because, if we don't have that, our potential adopters while assessing our
product may walk away, and our existing adopter - even after an upgrade to
a more recent or future release without this - will have an extremely hard
time analysing who created and changed records (the what, where and when
questions) when confronted with nefarious (criminal) users.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Fri, Apr 26, 2019 at 9:00 AM Pritam Kute <[hidden email]>
wrote:

> IMO, adding 'createdByUserLogin' and 'lastModifiedByUserLogin' fields to
> every entity is not that useful. Like for example, if we consider the
> "Visit" entity, I am not able to find any advantage of having these fields
> in this entity. But, it should be added to some crucial entities like
> OrderHeader, OrderItem, ProductPrice(which is already there) to track the
> things like who dod the last price updates or order updates.
>
> Kind Regards,
> --
> Pritam Kute
>
>
> On Thu, Apr 25, 2019 at 6:10 PM Jacques Le Roux <
> [hidden email]> wrote:
>
> > Le 25/04/2019 à 14:17, Suraj Khurana a écrit :
> > > IMO, this is configurable as Jacques pointed, so need to take any
> action.
> > > In fact, I would suggest showing these fields while searching for any
> > data
> > > from entity-engine in webtools, because they are really helpful while
> > > working in a dev environment for debugging.
> >
> > This could be configurable indeed (less need in production for instance
> so
> > default would be false)
> >
> > Jacques
> >
> > >
> > > Just my two cents !!!
> > >
> > > --
> > > Best Regards,
> > > Suraj Khurana
> > > TECHNICAL CONSULTANT
> > > mobile: [phone]
> > > email: [hidden email]
> > > www.hotwax.co
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Wed, Apr 24, 2019 at 7:14 PM Jacques Le Roux <
> > > [hidden email]> wrote:
> > >
> > >> A bit out of subject, just to complete the discussion because nobody
> > spoke
> > >> about.
> > >>
> > >> The entities are defined with no-auto-stamp="false" by default so it's
> > >> possible to change this default.
> > >>
> > >> Of course 'createdByUserLogin' and 'lastModifiedByUserLogin' fields
> are
> > >> not concerned, it was just to complete
> > >>
> > >> Jacques
> > >>
> > >>
> > >> Le 24/04/2019 à 13:36, Rishi Solanki a écrit :
> > >>> Michael,
> > >>> Thank you for details, all makes sense.
> > >>>
> > >>> Best Regards,
> > >>> --
> > >>> *Rishi Solanki* | Sr Manager, Enterprise Software Development
> > >>> HotWax Systems <http://www.hotwaxsystems.com/>
> > >>> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> > >> Indore,
> > >>> M.P 452010
> > >>> Linkedin: *Rishi Solanki*
> > >>> <https://www.linkedin.com/in/rishi-solanki-62271b7/>
> > >>> Direct: [phone]
> > >>>
> > >>>
> > >>> On Wed, Apr 24, 2019 at 4:37 PM Michael Brohl <
> > [hidden email]>
> > >>> wrote:
> > >>>
> > >>>> I have not time to elaborate in-depth right now, but just a quick
> food
> > >>>> for thought:
> > >>>>
> > >>>> Having these fields in every entity *by default* allows detailed
> > >>>> tracking of users which might be unwanted. I know that this is a
> > >>>> sensible topic in companies and affects privacy protection.
> > >>>>
> > >>>> I am not sure how the selection of entities with these fields was
> > done,
> > >>>> maybe others can add insights.
> > >>>>
> > >>>> Regards,
> > >>>>
> > >>>> Michael Brohl
> > >>>>
> > >>>> ecomify GmbH - www.ecomify.de
> > >>>>
> > >>>>
> > >>>> Am 24.04.19 um 12:40 schrieb Pierre Smits:
> > >>>>> Thanks Michael,
> > >>>>>
> > >>>>> So we should keep those *TxStamp fields.
> > >>>>>
> > >>>>> But what about the second suggestion about having the
> > >>>> 'createdByUserLogin'
> > >>>>> and 'lastModifiedByUserLogin'  fields added to the internal fields
> > set?
> > >>>>>
> > >>>>> Best regards,
> > >>>>>
> > >>>>> Pierre Smits
> > >>>>>
> > >>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > >>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
> > >>>>> Apache Incubator <https://incubator.apache.org>, committer
> > >>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> > >>>> privileges)
> > >>>>> since 2008*
> > >>>>> Apache Steve <https://steve.apache.org>, committer
> > >>>>>
> > >>>>>
> > >>>>> On Wed, Apr 24, 2019 at 12:20 PM Michael Brohl <
> > >> [hidden email]
> > >>>>> wrote:
> > >>>>>
> > >>>>>> These fields are not the same, they can differ. The TX fields mark
> > the
> > >>>>>> transaction timestamp while the non TX fields mark the "real"
> update
> > >>>>>> time. You can see it when you watch closely in the database. All
> > >> changes
> > >>>>>> made within an transaction have the same tx timestamp.
> > >>>>>>
> > >>>>>> Regards,
> > >>>>>>
> > >>>>>> Michael Brohl
> > >>>>>>
> > >>>>>> ecomify GmbH - www.ecomify.de
> > >>>>>>
> > >>>>>>
> > >>>>>> Am 24.04.19 um 09:48 schrieb Pierre Smits:
> > >>>>>>> Hi All,
> > >>>>>>>
> > >>>>>>> Currently our functions inject following internal fields into the
> > >> model
> > >>>>>> of
> > >>>>>>> each entity:
> > >>>>>>>
> > >>>>>>>        - createdStamp
> > >>>>>>>        - createdTxStamp
> > >>>>>>>        - lastUpdatedStamp
> > >>>>>>>        - lastUpdatedTxStamp
> > >>>>>>>
> > >>>>>>> All of the fields above are of the field type definition
> > 'date-time',
> > >>>>>>> giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This
> > >> means
> > >>>>>>> that the createdTxStamp is the same as createdStamp  and
> > >>>>>> lastUpdatedTxStamp
> > >>>>>>> is the same as lastUpdatedStamp.
> > >>>>>>>
> > >>>>>>> Should we get rid of the redundant fields?
> > >>>>>>>
> > >>>>>>> Also, a lot of entity definitions in the various models have the
> > >>>>>>> 'createdByUserLogin' and 'lastModifiedByUserLogin' added.
> > >>>>>>>
> > >>>>>>> Should we have these fields added to the internal fields set so
> > that
> > >>>>>> these
> > >>>>>>> are always injected into the model of each entity, and always
> > filled?
> > >>>>>>>
> > >>>>>>> Best regards,
> > >>>>>>>
> > >>>>>>> Pierre Smits
> > >>>>>>>
> > >>>>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice
> President*
> > >>>>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
> > >>>>>>> Apache Incubator <https://incubator.apache.org>, committer
> > >>>>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> > >>>>>> privileges)
> > >>>>>>> since 2008*
> > >>>>>>> Apache Steve <https://steve.apache.org>, committer
> > >>>>>>>
> >
>

[Gil Portenseigne]

Hello Pierre,

If you have specific need of Auditing, after suspition of malicious
users, you can enable entity_audit_log feature on the desired table.
At a cost of performance loss.

I do not understand why impersonation feature appears here, since it is
a administrator specific feature. If an admin is malicious, having those
fields cannot prevent him to destroy/modify/create or do whatever with
the data.

Like you can guess, my opinion, is not to put those fields onto all
entity in OFBiz.

I agree that security is important, and OFBiz admin must grant the good
permission to the trusted users.

If you find out that specific entity miss those fields, it can be added
case by case. But i do not feel ok into a global feature.

Regards

Gil

Le 11:17 - vendredi 26 avril, Pierre Smits a écrit :

> The two fields are extremely useful (even indispensable) regarding auditing
> and data analysis. Consider security assessments and fraud
> detection/prevention.
>
> In trunk, only 48 entities have those fields in following breakdown:
> Component Model Entities Having UserLogin fields %
> datamodel accounting 160 3 1,88%
> datamodel content 64 7 10,94%
> datamodel humanres 41 1 2,44%
> datamodel manufacturing 7   0,00%
> datamodel marketing 32 8 25,00%
> datamodel order 106 10 9,43%
> datamodel party 81 2 2,47%
> datamodel product 168 11 6,55%
> datamodel facility 38 4 10,53%
> datamodel workeffort 40 1 2,50%
>   In apps 737 47 6,38%
>   in framework 98 1 1,02%
> Total   835 48 5,75%
>
> That means that for the majority of the entities (more than 90%) our
> adopters (using the data models OOTB) have no way of telling who created a
> record and who modified it last. And we are talking about entities
> regarding invoices, payments, gl transaction entries, orders, quotes,
> product definitions, inventory quantities and locations, receipts,
> deliveries etc., all which contain business critical data.
>
> But also, with the recently feature regarding impersonation added to our
> code base which allow other users to change records through OFBiz having
> those two fields on each entity becomes business critical.
>
> IMO the OFBiz should have these two fields established on each entity OOTB.
>
> Because, if we don't have that, our potential adopters while assessing our
> product may walk away, and our existing adopter - even after an upgrade to
> a more recent or future release without this - will have an extremely hard
> time analysing who created and changed records (the what, where and when
> questions) when confronted with nefarious (criminal) users.
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
> since 2008*
> Apache Steve <https://steve.apache.org>, committer
>
>
> On Fri, Apr 26, 2019 at 9:00 AM Pritam Kute <[hidden email]>
> wrote:
>
> > IMO, adding 'createdByUserLogin' and 'lastModifiedByUserLogin' fields to
> > every entity is not that useful. Like for example, if we consider the
> > "Visit" entity, I am not able to find any advantage of having these fields
> > in this entity. But, it should be added to some crucial entities like
> > OrderHeader, OrderItem, ProductPrice(which is already there) to track the
> > things like who dod the last price updates or order updates.
> >
> > Kind Regards,
> > --
> > Pritam Kute
> >
> >
> > On Thu, Apr 25, 2019 at 6:10 PM Jacques Le Roux <
> > [hidden email]> wrote:
> >
> > > Le 25/04/2019 à 14:17, Suraj Khurana a écrit :
> > > > IMO, this is configurable as Jacques pointed, so need to take any
> > action.
> > > > In fact, I would suggest showing these fields while searching for any
> > > data
> > > > from entity-engine in webtools, because they are really helpful while
> > > > working in a dev environment for debugging.
> > >
> > > This could be configurable indeed (less need in production for instance
> > so
> > > default would be false)
> > >
> > > Jacques
> > >
> > > >
> > > > Just my two cents !!!
> > > >
> > > > --
> > > > Best Regards,
> > > > Suraj Khurana
> > > > TECHNICAL CONSULTANT
> > > > mobile: [phone]
> > > > email: [hidden email]
> > > > www.hotwax.co
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Apr 24, 2019 at 7:14 PM Jacques Le Roux <
> > > > [hidden email]> wrote:
> > > >
> > > >> A bit out of subject, just to complete the discussion because nobody
> > > spoke
> > > >> about.
> > > >>
> > > >> The entities are defined with no-auto-stamp="false" by default so it's
> > > >> possible to change this default.
> > > >>
> > > >> Of course 'createdByUserLogin' and 'lastModifiedByUserLogin' fields
> > are
> > > >> not concerned, it was just to complete
> > > >>
> > > >> Jacques
> > > >>
> > > >>
> > > >> Le 24/04/2019 à 13:36, Rishi Solanki a écrit :
> > > >>> Michael,
> > > >>> Thank you for details, all makes sense.
> > > >>>
> > > >>> Best Regards,
> > > >>> --
> > > >>> *Rishi Solanki* | Sr Manager, Enterprise Software Development
> > > >>> HotWax Systems <http://www.hotwaxsystems.com/>
> > > >>> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> > > >> Indore,
> > > >>> M.P 452010
> > > >>> Linkedin: *Rishi Solanki*
> > > >>> <https://www.linkedin.com/in/rishi-solanki-62271b7/>
> > > >>> Direct: [phone]
> > > >>>
> > > >>>
> > > >>> On Wed, Apr 24, 2019 at 4:37 PM Michael Brohl <
> > > [hidden email]>
> > > >>> wrote:
> > > >>>
> > > >>>> I have not time to elaborate in-depth right now, but just a quick
> > food
> > > >>>> for thought:
> > > >>>>
> > > >>>> Having these fields in every entity *by default* allows detailed
> > > >>>> tracking of users which might be unwanted. I know that this is a
> > > >>>> sensible topic in companies and affects privacy protection.
> > > >>>>
> > > >>>> I am not sure how the selection of entities with these fields was
> > > done,
> > > >>>> maybe others can add insights.
> > > >>>>
> > > >>>> Regards,
> > > >>>>
> > > >>>> Michael Brohl
> > > >>>>
> > > >>>> ecomify GmbH - www.ecomify.de
> > > >>>>
> > > >>>>
> > > >>>> Am 24.04.19 um 12:40 schrieb Pierre Smits:
> > > >>>>> Thanks Michael,
> > > >>>>>
> > > >>>>> So we should keep those *TxStamp fields.
> > > >>>>>
> > > >>>>> But what about the second suggestion about having the
> > > >>>> 'createdByUserLogin'
> > > >>>>> and 'lastModifiedByUserLogin'  fields added to the internal fields
> > > set?
> > > >>>>>
> > > >>>>> Best regards,
> > > >>>>>
> > > >>>>> Pierre Smits
> > > >>>>>
> > > >>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > > >>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
> > > >>>>> Apache Incubator <https://incubator.apache.org>, committer
> > > >>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> > > >>>> privileges)
> > > >>>>> since 2008*
> > > >>>>> Apache Steve <https://steve.apache.org>, committer
> > > >>>>>
> > > >>>>>
> > > >>>>> On Wed, Apr 24, 2019 at 12:20 PM Michael Brohl <
> > > >> [hidden email]
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>> These fields are not the same, they can differ. The TX fields mark
> > > the
> > > >>>>>> transaction timestamp while the non TX fields mark the "real"
> > update
> > > >>>>>> time. You can see it when you watch closely in the database. All
> > > >> changes
> > > >>>>>> made within an transaction have the same tx timestamp.
> > > >>>>>>
> > > >>>>>> Regards,
> > > >>>>>>
> > > >>>>>> Michael Brohl
> > > >>>>>>
> > > >>>>>> ecomify GmbH - www.ecomify.de
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Am 24.04.19 um 09:48 schrieb Pierre Smits:
> > > >>>>>>> Hi All,
> > > >>>>>>>
> > > >>>>>>> Currently our functions inject following internal fields into the
> > > >> model
> > > >>>>>> of
> > > >>>>>>> each entity:
> > > >>>>>>>
> > > >>>>>>>        - createdStamp
> > > >>>>>>>        - createdTxStamp
> > > >>>>>>>        - lastUpdatedStamp
> > > >>>>>>>        - lastUpdatedTxStamp
> > > >>>>>>>
> > > >>>>>>> All of the fields above are of the field type definition
> > > 'date-time',
> > > >>>>>>> giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This
> > > >> means
> > > >>>>>>> that the createdTxStamp is the same as createdStamp  and
> > > >>>>>> lastUpdatedTxStamp
> > > >>>>>>> is the same as lastUpdatedStamp.
> > > >>>>>>>
> > > >>>>>>> Should we get rid of the redundant fields?
> > > >>>>>>>
> > > >>>>>>> Also, a lot of entity definitions in the various models have the
> > > >>>>>>> 'createdByUserLogin' and 'lastModifiedByUserLogin' added.
> > > >>>>>>>
> > > >>>>>>> Should we have these fields added to the internal fields set so
> > > that
> > > >>>>>> these
> > > >>>>>>> are always injected into the model of each entity, and always
> > > filled?
> > > >>>>>>>
> > > >>>>>>> Best regards,
> > > >>>>>>>
> > > >>>>>>> Pierre Smits
> > > >>>>>>>
> > > >>>>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice
> > President*
> > > >>>>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
> > > >>>>>>> Apache Incubator <https://incubator.apache.org>, committer
> > > >>>>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> > > >>>>>> privileges)
> > > >>>>>>> since 2008*
> > > >>>>>>> Apache Steve <https://steve.apache.org>, committer
> > > >>>>>>>
> > >
> >

[Pierre Smits-3]

Gill, all,

The entity_audit_log feature also sprung into my mind shortly after I
posted my comment.

I wonder how many of our adopters are aware of this feature and the penalty
aspect in production setups. And of how many do we in this project know
that these adopters are aware?
Such info rarely trickles back into our mailing lists.
Even in this community there hasn't been much traffic regarding that
subject over the years. Markmail (see [1]) revealed that they have only
just over a 100 postings registered.

And isn't so, that when an adopter suspects foul play this often already
has happened. Enabling the entity_audit_log feature after suspicion of foul
play is like closing the barn after the horse has beens stolen.

But lets address the 'what is required to have the entity_audit_log-feature
operational' for a moment.
I did a google search on the subject and I found nothing (substantial)
about this feature that explains how it functions and what is required to
have it operational.
From what I got from memory recollection and recent searches, that this
only works for fields that have the 'enable-audit-log' attribute set to
"true" in the entity-models. I found only 10 fields in the various
applications component have such an attribute setting (only 2 entities in
order-entity.model: OrderItem and ReturnItem . Non of the other fields in
the entity models have have the 'enable-audit-log' set to 'false'.

And you are correct, this feature comes with a processing penalty, which
increases with the number of fields marked for auditing. That is the first
-1 about having to do analysis on who created and changed what, where and
when.

The second -1 about the 'enable_audit_log'-feature is that, even when an
adopter is having the 'audit' and the entity_audit_log feature on his mind
and wants it operational for more business critical fields in then his
implementation project will increase as all the entities need to be
enhanced regarding those fields. Plus in this feature for audit trails and
fraud detection it requires fields that capture the UserLogin values
(createdBy and lastModifiedBy). In current code base even less entity have
a field that captures the userLogin (12, through the changeByUserLoginId
field).

The third -1 is that this feature doesn't appear have a property setting to
enable or disable the feature in underlying services. That means it is
always on, and dependent on the entity-model changes. When the adopter
suspects foul play he can't simply change a property setting to temporarily
take the performance penalty to confirm or debunk his suspicion. Nor  does
he have functionalities available to enable/disable specific fields
dynamically through the UI (of e.g. web tools).

And last but not least: he fourth -1 regarding the
'enable_audit_log'-feature is that it doesn't appear to be working as
expected. I did a cursory test with an order some moments ago in ofbiz (see
[1]) and it does not capture the old values on the line items. But I may be
misunderstanding the screen/process there.

All in all, there are a lot of technical +1s in favour of having the
createdByUserlogin and lastModifiedByUserLogin added through the internal
fields injection process. The implementation in the code base by the
community can be achieved fairly fast. The impact on migration (for
existing adopters planning to upgrade) is rather small, as it only extends
the model with 2 fields (added at the end) and easily explained. And it
offers additional business-case benefits for those considering to use the
product for their mission critical business processes.

[1]
https://ofbiz.markmail.org/search/?q=enable-audit-log#query:enable-audit-log+page:1+state:facets

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Fri, Apr 26, 2019 at 12:17 PM Gil Portenseigne <
[hidden email]> wrote:

> Hello Pierre,
>
> If you have specific need of Auditing, after suspition of malicious
> users, you can enable entity_audit_log feature on the desired table.
> At a cost of performance loss.
>
> I do not understand why impersonation feature appears here, since it is
> a administrator specific feature. If an admin is malicious, having those
> fields cannot prevent him to destroy/modify/create or do whatever with
> the data.
>
> Like you can guess, my opinion, is not to put those fields onto all
> entity in OFBiz.
>
> I agree that security is important, and OFBiz admin must grant the good
> permission to the trusted users.
>
> If you find out that specific entity miss those fields, it can be added
> case by case. But i do not feel ok into a global feature.
>
> Regards
>
> Gil
>
>

[Scott Gray-3]

Fwiw more often than not I can identify who made a specific change by
searching the logs, assuming they're retained for long enough. Most http
requests log the session ID (when the view is rendered) which can then be
matched to a user via the Visit table.

I'm not sure if that has changed in recent versions but I've used it many
times over the years.

Regards
Scott

On Sat, 27 Apr 2019, 00:23 Pierre Smits, <[hidden email]> wrote:

> Gill, all,
>
> The entity_audit_log feature also sprung into my mind shortly after I
> posted my comment.
>
> I wonder how many of our adopters are aware of this feature and the penalty
> aspect in production setups. And of how many do we in this project know
> that these adopters are aware?
> Such info rarely trickles back into our mailing lists.
> Even in this community there hasn't been much traffic regarding that
> subject over the years. Markmail (see [1]) revealed that they have only
> just over a 100 postings registered.
>
> And isn't so, that when an adopter suspects foul play this often already
> has happened. Enabling the entity_audit_log feature after suspicion of foul
> play is like closing the barn after the horse has beens stolen.
>
> But lets address the 'what is required to have the entity_audit_log-feature
> operational' for a moment.
> I did a google search on the subject and I found nothing (substantial)
> about this feature that explains how it functions and what is required to
> have it operational.
> From what I got from memory recollection and recent searches, that this
> only works for fields that have the 'enable-audit-log' attribute set to
> "true" in the entity-models. I found only 10 fields in the various
> applications component have such an attribute setting (only 2 entities in
> order-entity.model: OrderItem and ReturnItem . Non of the other fields in
> the entity models have have the 'enable-audit-log' set to 'false'.
>
> And you are correct, this feature comes with a processing penalty, which
> increases with the number of fields marked for auditing. That is the first
> -1 about having to do analysis on who created and changed what, where and
> when.
>
> The second -1 about the 'enable_audit_log'-feature is that, even when an
> adopter is having the 'audit' and the entity_audit_log feature on his mind
> and wants it operational for more business critical fields in then his
> implementation project will increase as all the entities need to be
> enhanced regarding those fields. Plus in this feature for audit trails and
> fraud detection it requires fields that capture the UserLogin values
> (createdBy and lastModifiedBy). In current code base even less entity have
> a field that captures the userLogin (12, through the changeByUserLoginId
> field).
>
> The third -1 is that this feature doesn't appear have a property setting to
> enable or disable the feature in underlying services. That means it is
> always on, and dependent on the entity-model changes. When the adopter
> suspects foul play he can't simply change a property setting to temporarily
> take the performance penalty to confirm or debunk his suspicion. Nor  does
> he have functionalities available to enable/disable specific fields
> dynamically through the UI (of e.g. web tools).
>
> And last but not least: he fourth -1 regarding the
> 'enable_audit_log'-feature is that it doesn't appear to be working as
> expected. I did a cursory test with an order some moments ago in ofbiz (see
> [1]) and it does not capture the old values on the line items. But I may be
> misunderstanding the screen/process there.
>
> All in all, there are a lot of technical +1s in favour of having the
> createdByUserlogin and lastModifiedByUserLogin added through the internal
> fields injection process. The implementation in the code base by the
> community can be achieved fairly fast. The impact on migration (for
> existing adopters planning to upgrade) is rather small, as it only extends
> the model with 2 fields (added at the end) and easily explained. And it
> offers additional business-case benefits for those considering to use the
> product for their mission critical business processes.
>
> [1]
>
> https://ofbiz.markmail.org/search/?q=enable-audit-log#query:enable-audit-log+page:1+state:facets
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
> since 2008*
> Apache Steve <https://steve.apache.org>, committer
>
>
> On Fri, Apr 26, 2019 at 12:17 PM Gil Portenseigne <
> [hidden email]> wrote:
>
> > Hello Pierre,
> >
> > If you have specific need of Auditing, after suspition of malicious
> > users, you can enable entity_audit_log feature on the desired table.
> > At a cost of performance loss.
> >
> > I do not understand why impersonation feature appears here, since it is
> > a administrator specific feature. If an admin is malicious, having those
> > fields cannot prevent him to destroy/modify/create or do whatever with
> > the data.
> >
> > Like you can guess, my opinion, is not to put those fields onto all
> > entity in OFBiz.
> >
> > I agree that security is important, and OFBiz admin must grant the good
> > permission to the trusted users.
> >
> > If you find out that specific entity miss those fields, it can be added
> > case by case. But i do not feel ok into a global feature.
> >
> > Regards
> >
> > Gil
> >
> >
>

[Gil Portenseigne]

A big post for saying that the feature i just wanted to recall about do
not fit your need :).

I used it in the past for a critical audit, and was happy with it.


Le 14:23 - vendredi 26 avril, Pierre Smits a écrit :
> Gill, all,
>
> The entity_audit_log feature also sprung into my mind shortly after I
> posted my comment.
>

[...]

> And last but not least: he fourth -1 regarding the
> 'enable_audit_log'-feature is that it doesn't appear to be working as
> expected. I did a cursory test with an order some moments ago in ofbiz (see
> [1]) and it does not capture the old values on the line items. But I may be
> misunderstanding the screen/process there.

In my experience i got old and new value, date and userLogin.

Regards,

[Jacques Le Roux]

Hi Pritam, All,

To clarify, in case there is a confusion here. If I'm not wrong Suraj suggested to add the auto-stamp fields in "entity-engine in webtools".

Like for instance at https://demo-trunk.ofbiz.apache.org/webtools/control/FindGeneric?entityName=OrderHeader

He did not speak about the 'createdByUserLogin' and 'lastModifiedByUserLogin' fields, please Suraj confirm.

Then I agreed but suggested that it was not a default but implemented with a properties to be used during development mostly

Thanks

Jacques

Le 26/04/2019 à 09:00, Pritam Kute a écrit :

> IMO, adding 'createdByUserLogin' and 'lastModifiedByUserLogin' fields to
> every entity is not that useful. Like for example, if we consider the
> "Visit" entity, I am not able to find any advantage of having these fields
> in this entity. But, it should be added to some crucial entities like
> OrderHeader, OrderItem, ProductPrice(which is already there) to track the
> things like who dod the last price updates or order updates.
>
> Kind Regards,
> --
> Pritam Kute
>
>
> On Thu, Apr 25, 2019 at 6:10 PM Jacques Le Roux <
> [hidden email]> wrote:
>
>> Le 25/04/2019 à 14:17, Suraj Khurana a écrit :
>>> IMO, this is configurable as Jacques pointed, so need to take any action.
>>> In fact, I would suggest showing these fields while searching for any
>> data
>>> from entity-engine in webtools, because they are really helpful while
>>> working in a dev environment for debugging.
>> This could be configurable indeed (less need in production for instance so
>> default would be false)
>>
>> Jacques
>>
>>> Just my two cents !!!
>>>
>>> --
>>> Best Regards,
>>> Suraj Khurana
>>> TECHNICAL CONSULTANT
>>> mobile: [phone]
>>> email: [hidden email]
>>> www.hotwax.co
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Apr 24, 2019 at 7:14 PM Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>>> A bit out of subject, just to complete the discussion because nobody
>> spoke
>>>> about.
>>>>
>>>> The entities are defined with no-auto-stamp="false" by default so it's
>>>> possible to change this default.
>>>>
>>>> Of course 'createdByUserLogin' and 'lastModifiedByUserLogin' fields are
>>>> not concerned, it was just to complete
>>>>
>>>> Jacques
>>>>
>>>>
>>>> Le 24/04/2019 à 13:36, Rishi Solanki a écrit :
>>>>> Michael,
>>>>> Thank you for details, all makes sense.
>>>>>
>>>>> Best Regards,
>>>>> --
>>>>> *Rishi Solanki* | Sr Manager, Enterprise Software Development
>>>>> HotWax Systems <http://www.hotwaxsystems.com/>
>>>>> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
>>>> Indore,
>>>>> M.P 452010
>>>>> Linkedin: *Rishi Solanki*
>>>>> <https://www.linkedin.com/in/rishi-solanki-62271b7/>
>>>>> Direct: [phone]
>>>>>
>>>>>
>>>>> On Wed, Apr 24, 2019 at 4:37 PM Michael Brohl <
>> [hidden email]>
>>>>> wrote:
>>>>>
>>>>>> I have not time to elaborate in-depth right now, but just a quick food
>>>>>> for thought:
>>>>>>
>>>>>> Having these fields in every entity *by default* allows detailed
>>>>>> tracking of users which might be unwanted. I know that this is a
>>>>>> sensible topic in companies and affects privacy protection.
>>>>>>
>>>>>> I am not sure how the selection of entities with these fields was
>> done,
>>>>>> maybe others can add insights.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Michael Brohl
>>>>>>
>>>>>> ecomify GmbH - www.ecomify.de
>>>>>>
>>>>>>
>>>>>> Am 24.04.19 um 12:40 schrieb Pierre Smits:
>>>>>>> Thanks Michael,
>>>>>>>
>>>>>>> So we should keep those *TxStamp fields.
>>>>>>>
>>>>>>> But what about the second suggestion about having the
>>>>>> 'createdByUserLogin'
>>>>>>> and 'lastModifiedByUserLogin'  fields added to the internal fields
>> set?
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Pierre Smits
>>>>>>>
>>>>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
>>>>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
>>>>>>> Apache Incubator <https://incubator.apache.org>, committer
>>>>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
>>>>>> privileges)
>>>>>>> since 2008*
>>>>>>> Apache Steve <https://steve.apache.org>, committer
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Apr 24, 2019 at 12:20 PM Michael Brohl <
>>>> [hidden email]
>>>>>>> wrote:
>>>>>>>
>>>>>>>> These fields are not the same, they can differ. The TX fields mark
>> the
>>>>>>>> transaction timestamp while the non TX fields mark the "real" update
>>>>>>>> time. You can see it when you watch closely in the database. All
>>>> changes
>>>>>>>> made within an transaction have the same tx timestamp.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Michael Brohl
>>>>>>>>
>>>>>>>> ecomify GmbH - www.ecomify.de
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 24.04.19 um 09:48 schrieb Pierre Smits:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Currently our functions inject following internal fields into the
>>>> model
>>>>>>>> of
>>>>>>>>> each entity:
>>>>>>>>>
>>>>>>>>>         - createdStamp
>>>>>>>>>         - createdTxStamp
>>>>>>>>>         - lastUpdatedStamp
>>>>>>>>>         - lastUpdatedTxStamp
>>>>>>>>>
>>>>>>>>> All of the fields above are of the field type definition
>> 'date-time',
>>>>>>>>> giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This
>>>> means
>>>>>>>>> that the createdTxStamp is the same as createdStamp  and
>>>>>>>> lastUpdatedTxStamp
>>>>>>>>> is the same as lastUpdatedStamp.
>>>>>>>>>
>>>>>>>>> Should we get rid of the redundant fields?
>>>>>>>>>
>>>>>>>>> Also, a lot of entity definitions in the various models have the
>>>>>>>>> 'createdByUserLogin' and 'lastModifiedByUserLogin' added.
>>>>>>>>>
>>>>>>>>> Should we have these fields added to the internal fields set so
>> that
>>>>>>>> these
>>>>>>>>> are always injected into the model of each entity, and always
>> filled?
>>>>>>>>> Best regards,
>>>>>>>>>
>>>>>>>>> Pierre Smits
>>>>>>>>>
>>>>>>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
>>>>>>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
>>>>>>>>> Apache Incubator <https://incubator.apache.org>, committer
>>>>>>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
>>>>>>>> privileges)
>>>>>>>>> since 2008*
>>>>>>>>> Apache Steve <https://steve.apache.org>, committer
>>>>>>>>>

[Deepak Dixit-4]

I think here we are mixing two different thread.

>>>auto-stamp fields in "entity-engine in webtools"

As I understand in this thread we are talking about only view part of find
generic entity page.
Here we are not talking about adding or removing fields in the entity. If
an entity has stamp filed it should display on webtools find generic page,
as it helps while debugging issues.

Please correct me if I misunderstood anything.

Kind Regards,
Deepak Dixit


On Fri, Apr 26, 2019 at 6:38 PM Jacques Le Roux <
[hidden email]> wrote:

> Hi Pritam, All,
>
> To clarify, in case there is a confusion here. If I'm not wrong Suraj
> suggested to add the auto-stamp fields in "entity-engine in webtools".
>
> Like for instance at
> https://demo-trunk.ofbiz.apache.org/webtools/control/FindGeneric?entityName=OrderHeader
>
> He did not speak about the 'createdByUserLogin' and
> 'lastModifiedByUserLogin' fields, please Suraj confirm.
>
> Then I agreed but suggested that it was not a default but implemented with
> a properties to be used during development mostly
>
> Thanks
>
> Jacques
>
> Le 26/04/2019 à 09:00, Pritam Kute a écrit :
> > IMO, adding 'createdByUserLogin' and 'lastModifiedByUserLogin' fields to
> > every entity is not that useful. Like for example, if we consider the
> > "Visit" entity, I am not able to find any advantage of having these
> fields
> > in this entity. But, it should be added to some crucial entities like
> > OrderHeader, OrderItem, ProductPrice(which is already there) to track the
> > things like who dod the last price updates or order updates.
> >
> > Kind Regards,
> > --
> > Pritam Kute
> >
> >
> > On Thu, Apr 25, 2019 at 6:10 PM Jacques Le Roux <
> > [hidden email]> wrote:
> >
> >> Le 25/04/2019 à 14:17, Suraj Khurana a écrit :
> >>> IMO, this is configurable as Jacques pointed, so need to take any
> action.
> >>> In fact, I would suggest showing these fields while searching for any
> >> data
> >>> from entity-engine in webtools, because they are really helpful while
> >>> working in a dev environment for debugging.
> >> This could be configurable indeed (less need in production for instance
> so
> >> default would be false)
> >>
> >> Jacques
> >>
> >>> Just my two cents !!!
> >>>
> >>> --
> >>> Best Regards,
> >>> Suraj Khurana
> >>> TECHNICAL CONSULTANT
> >>> mobile: [phone]
> >>> email: [hidden email]
> >>> www.hotwax.co
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, Apr 24, 2019 at 7:14 PM Jacques Le Roux <
> >>> [hidden email]> wrote:
> >>>
> >>>> A bit out of subject, just to complete the discussion because nobody
> >> spoke
> >>>> about.
> >>>>
> >>>> The entities are defined with no-auto-stamp="false" by default so it's
> >>>> possible to change this default.
> >>>>
> >>>> Of course 'createdByUserLogin' and 'lastModifiedByUserLogin' fields
> are
> >>>> not concerned, it was just to complete
> >>>>
> >>>> Jacques
> >>>>
> >>>>
> >>>> Le 24/04/2019 à 13:36, Rishi Solanki a écrit :
> >>>>> Michael,
> >>>>> Thank you for details, all makes sense.
> >>>>>
> >>>>> Best Regards,
> >>>>> --
> >>>>> *Rishi Solanki* | Sr Manager, Enterprise Software Development
> >>>>> HotWax Systems <http://www.hotwaxsystems.com/>
> >>>>> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> >>>> Indore,
> >>>>> M.P 452010
> >>>>> Linkedin: *Rishi Solanki*
> >>>>> <https://www.linkedin.com/in/rishi-solanki-62271b7/>
> >>>>> Direct: [phone]
> >>>>>
> >>>>>
> >>>>> On Wed, Apr 24, 2019 at 4:37 PM Michael Brohl <
> >> [hidden email]>
> >>>>> wrote:
> >>>>>
> >>>>>> I have not time to elaborate in-depth right now, but just a quick
> food
> >>>>>> for thought:
> >>>>>>
> >>>>>> Having these fields in every entity *by default* allows detailed
> >>>>>> tracking of users which might be unwanted. I know that this is a
> >>>>>> sensible topic in companies and affects privacy protection.
> >>>>>>
> >>>>>> I am not sure how the selection of entities with these fields was
> >> done,
> >>>>>> maybe others can add insights.
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>> Michael Brohl
> >>>>>>
> >>>>>> ecomify GmbH - www.ecomify.de
> >>>>>>
> >>>>>>
> >>>>>> Am 24.04.19 um 12:40 schrieb Pierre Smits:
> >>>>>>> Thanks Michael,
> >>>>>>>
> >>>>>>> So we should keep those *TxStamp fields.
> >>>>>>>
> >>>>>>> But what about the second suggestion about having the
> >>>>>> 'createdByUserLogin'
> >>>>>>> and 'lastModifiedByUserLogin'  fields added to the internal fields
> >> set?
> >>>>>>> Best regards,
> >>>>>>>
> >>>>>>> Pierre Smits
> >>>>>>>
> >>>>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> >>>>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
> >>>>>>> Apache Incubator <https://incubator.apache.org>, committer
> >>>>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> >>>>>> privileges)
> >>>>>>> since 2008*
> >>>>>>> Apache Steve <https://steve.apache.org>, committer
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Apr 24, 2019 at 12:20 PM Michael Brohl <
> >>>> [hidden email]
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> These fields are not the same, they can differ. The TX fields mark
> >> the
> >>>>>>>> transaction timestamp while the non TX fields mark the "real"
> update
> >>>>>>>> time. You can see it when you watch closely in the database. All
> >>>> changes
> >>>>>>>> made within an transaction have the same tx timestamp.
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>>
> >>>>>>>> Michael Brohl
> >>>>>>>>
> >>>>>>>> ecomify GmbH - www.ecomify.de
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Am 24.04.19 um 09:48 schrieb Pierre Smits:
> >>>>>>>>> Hi All,
> >>>>>>>>>
> >>>>>>>>> Currently our functions inject following internal fields into the
> >>>> model
> >>>>>>>> of
> >>>>>>>>> each entity:
> >>>>>>>>>
> >>>>>>>>>         - createdStamp
> >>>>>>>>>         - createdTxStamp
> >>>>>>>>>         - lastUpdatedStamp
> >>>>>>>>>         - lastUpdatedTxStamp
> >>>>>>>>>
> >>>>>>>>> All of the fields above are of the field type definition
> >> 'date-time',
> >>>>>>>>> giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This
> >>>> means
> >>>>>>>>> that the createdTxStamp is the same as createdStamp  and
> >>>>>>>> lastUpdatedTxStamp
> >>>>>>>>> is the same as lastUpdatedStamp.
> >>>>>>>>>
> >>>>>>>>> Should we get rid of the redundant fields?
> >>>>>>>>>
> >>>>>>>>> Also, a lot of entity definitions in the various models have the
> >>>>>>>>> 'createdByUserLogin' and 'lastModifiedByUserLogin' added.
> >>>>>>>>>
> >>>>>>>>> Should we have these fields added to the internal fields set so
> >> that
> >>>>>>>> these
> >>>>>>>>> are always injected into the model of each entity, and always
> >> filled?
> >>>>>>>>> Best regards,
> >>>>>>>>>
> >>>>>>>>> Pierre Smits
> >>>>>>>>>
> >>>>>>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice
> President*
> >>>>>>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
> >>>>>>>>> Apache Incubator <https://incubator.apache.org>, committer
> >>>>>>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> >>>>>>>> privileges)
> >>>>>>>>> since 2008*
> >>>>>>>>> Apache Steve <https://steve.apache.org>, committer
> >>>>>>>>>
>

[Suraj Khurana-2]

+1, Deepak Dixit.

--
Best Regards,
Suraj Khurana







On Sat, Apr 27, 2019 at 11:05 AM Deepak Dixit <[hidden email]>
wrote:

> I think here we are mixing two different thread.
>
> >>>auto-stamp fields in "entity-engine in webtools"
>
> As I understand in this thread we are talking about only view part of find
> generic entity page.
> Here we are not talking about adding or removing fields in the entity. If
> an entity has stamp filed it should display on webtools find generic page,
> as it helps while debugging issues.
>
> Please correct me if I misunderstood anything.
>
> Kind Regards,
> Deepak Dixit
>
>
> On Fri, Apr 26, 2019 at 6:38 PM Jacques Le Roux <
> [hidden email]> wrote:
>
> > Hi Pritam, All,
> >
> > To clarify, in case there is a confusion here. If I'm not wrong Suraj
> > suggested to add the auto-stamp fields in "entity-engine in webtools".
> >
> > Like for instance at
> >
> https://demo-trunk.ofbiz.apache.org/webtools/control/FindGeneric?entityName=OrderHeader
> >
> > He did not speak about the 'createdByUserLogin' and
> > 'lastModifiedByUserLogin' fields, please Suraj confirm.
> >
> > Then I agreed but suggested that it was not a default but implemented
> with
> > a properties to be used during development mostly
> >
> > Thanks
> >
> > Jacques
> >
> > Le 26/04/2019 à 09:00, Pritam Kute a écrit :
> > > IMO, adding 'createdByUserLogin' and 'lastModifiedByUserLogin' fields
> to
> > > every entity is not that useful. Like for example, if we consider the
> > > "Visit" entity, I am not able to find any advantage of having these
> > fields
> > > in this entity. But, it should be added to some crucial entities like
> > > OrderHeader, OrderItem, ProductPrice(which is already there) to track
> the
> > > things like who dod the last price updates or order updates.
> > >
> > > Kind Regards,
> > > --
> > > Pritam Kute
> > >
> > >
> > > On Thu, Apr 25, 2019 at 6:10 PM Jacques Le Roux <
> > > [hidden email]> wrote:
> > >
> > >> Le 25/04/2019 à 14:17, Suraj Khurana a écrit :
> > >>> IMO, this is configurable as Jacques pointed, so need to take any
> > action.
> > >>> In fact, I would suggest showing these fields while searching for any
> > >> data
> > >>> from entity-engine in webtools, because they are really helpful while
> > >>> working in a dev environment for debugging.
> > >> This could be configurable indeed (less need in production for
> instance
> > so
> > >> default would be false)
> > >>
> > >> Jacques
> > >>
> > >>> Just my two cents !!!
> > >>>
> > >>> --
> > >>> Best Regards,
> > >>> Suraj Khurana
> > >>> TECHNICAL CONSULTANT
> > >>> mobile: [phone]
> > >>> email: [hidden email]
> > >>> www.hotwax.co
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Wed, Apr 24, 2019 at 7:14 PM Jacques Le Roux <
> > >>> [hidden email]> wrote:
> > >>>
> > >>>> A bit out of subject, just to complete the discussion because nobody
> > >> spoke
> > >>>> about.
> > >>>>
> > >>>> The entities are defined with no-auto-stamp="false" by default so
> it's
> > >>>> possible to change this default.
> > >>>>
> > >>>> Of course 'createdByUserLogin' and 'lastModifiedByUserLogin' fields
> > are
> > >>>> not concerned, it was just to complete
> > >>>>
> > >>>> Jacques
> > >>>>
> > >>>>
> > >>>> Le 24/04/2019 à 13:36, Rishi Solanki a écrit :
> > >>>>> Michael,
> > >>>>> Thank you for details, all makes sense.
> > >>>>>
> > >>>>> Best Regards,
> > >>>>> --
> > >>>>> *Rishi Solanki* | Sr Manager, Enterprise Software Development
> > >>>>> HotWax Systems <http://www.hotwaxsystems.com/>
> > >>>>> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention
> Center,
> > >>>> Indore,
> > >>>>> M.P 452010
> > >>>>> Linkedin: *Rishi Solanki*
> > >>>>> <https://www.linkedin.com/in/rishi-solanki-62271b7/>
> > >>>>> Direct: [phone]
> > >>>>>
> > >>>>>
> > >>>>> On Wed, Apr 24, 2019 at 4:37 PM Michael Brohl <
> > >> [hidden email]>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> I have not time to elaborate in-depth right now, but just a quick
> > food
> > >>>>>> for thought:
> > >>>>>>
> > >>>>>> Having these fields in every entity *by default* allows detailed
> > >>>>>> tracking of users which might be unwanted. I know that this is a
> > >>>>>> sensible topic in companies and affects privacy protection.
> > >>>>>>
> > >>>>>> I am not sure how the selection of entities with these fields was
> > >> done,
> > >>>>>> maybe others can add insights.
> > >>>>>>
> > >>>>>> Regards,
> > >>>>>>
> > >>>>>> Michael Brohl
> > >>>>>>
> > >>>>>> ecomify GmbH - www.ecomify.de
> > >>>>>>
> > >>>>>>
> > >>>>>> Am 24.04.19 um 12:40 schrieb Pierre Smits:
> > >>>>>>> Thanks Michael,
> > >>>>>>>
> > >>>>>>> So we should keep those *TxStamp fields.
> > >>>>>>>
> > >>>>>>> But what about the second suggestion about having the
> > >>>>>> 'createdByUserLogin'
> > >>>>>>> and 'lastModifiedByUserLogin'  fields added to the internal
> fields
> > >> set?
> > >>>>>>> Best regards,
> > >>>>>>>
> > >>>>>>> Pierre Smits
> > >>>>>>>
> > >>>>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice
> President*
> > >>>>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
> > >>>>>>> Apache Incubator <https://incubator.apache.org>, committer
> > >>>>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> > >>>>>> privileges)
> > >>>>>>> since 2008*
> > >>>>>>> Apache Steve <https://steve.apache.org>, committer
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On Wed, Apr 24, 2019 at 12:20 PM Michael Brohl <
> > >>>> [hidden email]
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> These fields are not the same, they can differ. The TX fields
> mark
> > >> the
> > >>>>>>>> transaction timestamp while the non TX fields mark the "real"
> > update
> > >>>>>>>> time. You can see it when you watch closely in the database. All
> > >>>> changes
> > >>>>>>>> made within an transaction have the same tx timestamp.
> > >>>>>>>>
> > >>>>>>>> Regards,
> > >>>>>>>>
> > >>>>>>>> Michael Brohl
> > >>>>>>>>
> > >>>>>>>> ecomify GmbH - www.ecomify.de
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> Am 24.04.19 um 09:48 schrieb Pierre Smits:
> > >>>>>>>>> Hi All,
> > >>>>>>>>>
> > >>>>>>>>> Currently our functions inject following internal fields into
> the
> > >>>> model
> > >>>>>>>> of
> > >>>>>>>>> each entity:
> > >>>>>>>>>
> > >>>>>>>>>         - createdStamp
> > >>>>>>>>>         - createdTxStamp
> > >>>>>>>>>         - lastUpdatedStamp
> > >>>>>>>>>         - lastUpdatedTxStamp
> > >>>>>>>>>
> > >>>>>>>>> All of the fields above are of the field type definition
> > >> 'date-time',
> > >>>>>>>>> giving for java: java.sql.Timestamp, and for sql: TIMESTAMP.
> This
> > >>>> means
> > >>>>>>>>> that the createdTxStamp is the same as createdStamp  and
> > >>>>>>>> lastUpdatedTxStamp
> > >>>>>>>>> is the same as lastUpdatedStamp.
> > >>>>>>>>>
> > >>>>>>>>> Should we get rid of the redundant fields?
> > >>>>>>>>>
> > >>>>>>>>> Also, a lot of entity definitions in the various models have
> the
> > >>>>>>>>> 'createdByUserLogin' and 'lastModifiedByUserLogin' added.
> > >>>>>>>>>
> > >>>>>>>>> Should we have these fields added to the internal fields set so
> > >> that
> > >>>>>>>> these
> > >>>>>>>>> are always injected into the model of each entity, and always
> > >> filled?
> > >>>>>>>>> Best regards,
> > >>>>>>>>>
> > >>>>>>>>> Pierre Smits
> > >>>>>>>>>
> > >>>>>>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice
> > President*
> > >>>>>>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
> > >>>>>>>>> Apache Incubator <https://incubator.apache.org>, committer
> > >>>>>>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> > >>>>>>>> privileges)
> > >>>>>>>>> since 2008*
> > >>>>>>>>> Apache Steve <https://steve.apache.org>, committer
> > >>>>>>>>>
> >
>