OFBiz › OFBiz - User

Add created_by and updated_by to all tables ?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

16 messages Options

Deyan Tsvetanov-3

Add created_by and updated_by to all tables ?

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

BJ Freeman

Re: Add created_by and updated_by to all tables ?

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

Deyan Tsvetanov-3

Re: Add created_by and updated_by to all tables ?

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

BJ Freeman

Re: Add created_by and updated_by to all tables ?

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

Deyan Tsvetanov-3

Re: Add created_by and updated_by to all tables ?

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

BJ Freeman

Re: Add created_by and updated_by to all tables ?

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

Deyan Tsvetanov-3

Re: Add created_by and updated_by to all tables ?

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

David E. Jones-2

Re: Add created_by and updated_by to all tables ?

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

Deyan Tsvetanov-3

Re: Add created_by and updated_by to all tables ?

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

BJ Freeman

Re: Add created_by and updated_by to all tables ?

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

Deyan Tsvetanov-3

Re: Add created_by and updated_by to all tables ?

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

BJ Freeman

Re: Add created_by and updated_by to all tables ?

please note I am just giving alternatives to accomplish what you stated.
I am no way the end answer to this situation.
this is just a discussion.

if you want to submit a patch with your idea then do so.

Deyan Tsvetanov sent the following on 7/20/2010 1:47 PM:

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

Deyan Tsvetanov-3

Re: Add created_by and updated_by to all tables ?

In reply to this post by BJ Freeman

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

David E. Jones-2

Re: Add created_by and updated_by to all tables ?

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

Deyan Tsvetanov-3

Re: Add created_by and updated_by to all tables ?

In reply to this post by BJ Freeman

Yes,

I respect alternatives and discussion.
I am trying to suggest something that would increase ofbiz usability and
user satisfaction ( currently it is (very very very very very very)^n
low ). And I am getting only opinions why should it *not* be they way I
suggested and offers to do it some other way without getting pros and
cons for both of the methods.

I would appreciate if you told me: should we implement it your way we
could have these and these benefits but we shall have those and those
problems and those and those performance penalties and these and these
design issues

BUT

should we implement it the way I suggest we get blah and blah and we
avoid blah and blah.

But you are not :)

So if you like to continue the discussion you have to put some more
effort convincing me and the other users in the mail list about the
preference of one method over another :)

Peace and cheers
Deyan

On Tue, 2010-07-20 at 14:02 -0700, BJ Freeman wrote:

> please note I am just giving alternatives to accomplish what you stated.
> I am no way the end answer to this situation.
> this is just a discussion.
>
> if you want to submit a patch with your idea then do so.
>
>
> Deyan Tsvetanov sent the following on 7/20/2010 1:47 PM:
> > 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
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >
> >
> >

Deyan Tsvetanov-3

Re: Add created_by and updated_by to all tables ?

In reply to this post by David E. Jones-2

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