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 <pritam.k...@hotwaxsystems.com>
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 <
> jacques.le.r...@les7arts.com> 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: +91 9669750002
> > > email: suraj.khur...@hotwax.co
> > > www.hotwax.co
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Wed, Apr 24, 2019 at 7:14 PM Jacques Le Roux <
> > > jacques.le.r...@les7arts.com> 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: +91-9893287847
> > >>>
> > >>>
> > >>> On Wed, Apr 24, 2019 at 4:37 PM Michael Brohl <
> > michael.br...@ecomify.de>
> > >>> 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 <
> > >> michael.br...@ecomify.de
> > >>>>> 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
> > >>>>>>>
> >
>

Reply via email to