> 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
> >
> >
> >


Reply via email to