There's even a general auditing feature in the entity engine that saves changes, who changed it, when, visitId, etc. See the EntityAuditLog entity and the audit flag on the entity -> field element on an entity definition.
-David On Jul 19, 2010, at 11:36 PM, Deyan Tsvetanov wrote: > 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 >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>> >>> >>> > >
