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