ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deyan Tsvetanov <deyan_of...@flexbrix.com>
Subject Re: Add created_by and updated_by to all tables ?
Date Tue, 20 Jul 2010 05:36:44 GMT
Well for what is important there is already a changelog model -
party_status, party_name_history. 

If something else is needed we should we create it on demand. 

-- Deyan 

On Mon, 2010-07-19 at 14:57 -0700, BJ Freeman wrote:
> then if that ibnformaton is that important, should it not follow the 
> changelog model for audit, like changeprice?
> 
> Deyan Tsvetanov sent the following on 7/19/2010 9:01 AM:
> > Well I don't agree.
> >
> > A classic example of entities relation is party<- person.
> >
> > One could update only the Person entity - change the lastName. So we
> > update updated_by field only of the Person entity.
> >
> > One could update only the party entity - change the status - so we
> > update updated_by field only of the Party entity.
> >
> > I actually can not think of a table / entity that might not need the two
> > fields.
> >
> > Even if we take ENUMERATION_TYPE - it currently has created_stamp_tx and
> > updated_stamp_tx - why should it not have updated_by and created_by as
> > well ?
> >
> > -- Deyan
> >
> > On Mon, 2010-07-19 at 08:50 -0700, BJ Freeman wrote:
> >> an entity has a relationship with another entity.
> >> so if the main entity is updated those in the relationship will be tied
> >> to the main entity and don't need the two fields.
> >>
> >> yes those that are only updated by person should have the two fields, in
> >> my opinion.
> >>
> >> Deyan Tsvetanov sent the following on 7/19/2010 8:42 AM:
> >>>> Many entities data is not created without a dependence on another one
> >>>> so those should not need those two fields.
> >>>
> >>> This one i didn't understand :)
> >>>
> >>> In general data is being updated either by a person ( user or an
> >>> administrator or a consultant ) or by a process ( the system account ).
> >>>
> >>>
> >>>>
> >>>>
> >>> On Mon, 2010-07-19 at 08:29 -0700, BJ Freeman wrote:
> >>>> there are many operations that are generated by the system levels, such
> >>>> as status change. I can see the entities that are affected solely by
> >>>> users having those fields.
> >>>> I can see some being added but not every entity.
> >>>> Many entities data is not created without a dependence on another one
so
> >>>> those should not need those two fields.
> >>>>
> >>>>
> >>>> Deyan Tsvetanov sent the following on 7/19/2010 8:03 AM:
> >>>>> Hi guys,
> >>>>>
> >>>>> another suggestion: to add 2 mandatory fields created_by and updated_by
> >>>>> to all tables by default like created_stamp and updated_stamp. Currently
> >>>>> there columns are added on demand in the entity definition but they
are
> >>>>> often needed.
> >>>>>
> >>>>> Examples of usage:
> >>>>> 1)  status change - there is no created_by in the entity status
table -
> >>>>> party_status.
> >>>>> In general customers would like to know who and when disabled the
party
> >>>>> and who re-enabled it. The same applies to orders, invoices, etc.
> >>>>>
> >>>>> 2) Another example for using these 2 columns is entity lock. When
an
> >>>>> EntityLockedException is thrown it would be nice to include the
> >>>>> userLoginId of the user who updated the record as well as the time
so we
> >>>>> can notify the user:
> >>>>> "The record you are trying to save has been updated by Administrator,
> >>>>> The priviledged 5 minutes 32 secods ago. To cancel your request
and
> >>>>> reload the changes click reload. To go ahead and overwrite the changes
> >>>>> done by Administrator click "Overwrite". "
> >>>>> Or so ...
> >>>>>
> >>>>> 3) Record based security - users could be allowed to modify records
they
> >>>>> have created even without edit or admin permissions.
> >>>>>
> >>>>> Therefore it would be very very helpful if these 2 columns are present
> >>>>> by default, even if they allow null values to preserve the current
code
> >>>>> working.
> >>>>>
> >>>>> -- deyan
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >
> >
> >



Mime
View raw message