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
