ok,
forget it ...
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
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
> >
> >
> >
