For history -> we use audit logs, with out a doubt. For knowing the user who created the record -> we use createdByUserLogin and we don't need audit log.
For knowing the user who last modified the record -> we use updatedByUserLogin and we don't need audit log. The functionality we need here is to notify user A that user B modified the record while user A was editing it and if user A wants to overwrite it - he should go ahead with a warning OR he could refresh the data, observe the changes user B made, probably call him on the phone and discuss , etc. -- deyan On Wed, 2010-07-21 at 01:13 -0600, David E Jones wrote: > On the other hand, if you only have a single updatedByUserLoginId field you > don't have a history of changes and users who made them. Even with what you > are talking about here, ie adding that to the error message, it could be > wrong in that multiple updates could have happened since the optimistic lock > was started. > > Even the current created by and last updated by fields are a hack IMO, and > only marginally useful as it hides the history and only marginally shows what > happened. > > -David > > > On Jul 21, 2010, at 1:07 AM, Deyan Tsvetanov wrote: > > > #1 If I update 5 fields in a Person entity I would get 5 records in > > EntityAuditLog. If I need to get the userLoginId who updated the Person > > record I have to make a query in EntityAuditLog with a where clause, > > sort descending by created_stamp and get only the 1st result. There is a > > big performance penalty here. And I just need to get the userLoginId who > > updated the record so I include it into the EntityLockedException. > > > > #2 I don't want to create a page. I want to modify some services ( like > > updatePerson ) and let that service permit the user to update records > > created by himself if he has the permission > > PARTY_UPDATE_CREATED_BY_HIMSELF or whatever the permission name is going > > to be. > > > > Deyan > > > > On Tue, 2010-07-20 at 13:28 -0700, BJ Freeman wrote: > >> #1 how about the except is a try catch and the catch displays the last > >> two reocords related to the action from the EntityAuditLog. > >> > >> #2 have you looked at the myportal and how it shows only data done for > >> that login, that has roles and security? > >> you can have a page for EntityAuditLog that shows who changed what > >> relative to the page they are on. > >> > >> Deyan Tsvetanov sent the following on 7/19/2010 11:20 PM: > >>> What about the entity locking and record based security ? > >>> > >>> 1) When we enable locking for an entity and there is an exception we > >>> would like to know who modified the data before us. > >>> > >>> 2) Users enter data and have security permission PARTY_CREATE. They > >>> don't have permission PARTY_UPDATE or PARTYMGR_ADMIN. However they often > >>> make mistakes in the entered data and they would like to correct them. > >>> This we can solve by adding a security permission > >>> PARTY_UPDATE_SELF_CREATED or so which allows updating records created by > >>> the same user. > >>> > >>> -- Deyan > >>> > >>> On Mon, 2010-07-19 at 23:41 -0600, David E Jones wrote: > >>>> 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 > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >>> > > > > >
