Re: auto-stamp fields in "entity-engine in webtools". was [[Re: [PROPOSAL] DataModel - Improve Internal Fields injection]]

This is handled by OFBIZ-10959, so we can close this convo and use rather "[PROPOSAL] Enable entity timestamp fields" at https://markmail.org/message/x7paa3ulljns6awh if ever needed (OK there and in Jira for me) Jacques Le 27/04/2019 à 10:29, Jacques Le Roux a écrit : Thanks Deepak, Suraj,

Re: auto-stamp fields in "entity-engine in webtools". was [[Re: [PROPOSAL] DataModel - Improve Internal Fields injection]]

Thanks Deepak, Suraj, Yes, that's why I changed the title for this "sub-thread". Now the question is to agree about having those fields always visible while searching or it they should show only based on a properties. Are those of interest also in a production environment? Maybe they are not

Re: auto-stamp fields in "entity-engine in webtools". was [[Re: [PROPOSAL] DataModel - Improve Internal Fields injection]]

+1, Deepak Dixit. -- Best Regards, Suraj Khurana On Sat, Apr 27, 2019 at 11:05 AM Deepak Dixit wrote: > I think here we are mixing two different thread. > > >>>auto-stamp fields in "entity-engine in webtools" > > As I understand in this thread we are talking about only view part of find

Re: auto-stamp fields in "entity-engine in webtools". was [[Re: [PROPOSAL] DataModel - Improve Internal Fields injection]]

I think here we are mixing two different thread. >>>auto-stamp fields in "entity-engine in webtools" As I understand in this thread we are talking about only view part of find generic entity page. Here we are not talking about adding or removing fields in the entity. If an entity has stamp filed

auto-stamp fields in "entity-engine in webtools". was [[Re: [PROPOSAL] DataModel - Improve Internal Fields injection]]

Hi Pritam, All, To clarify, in case there is a confusion here. If I'm not wrong Suraj suggested to add the auto-stamp fields in "entity-engine in webtools". Like for instance at https://demo-trunk.ofbiz.apache.org/webtools/control/FindGeneric?entityName=OrderHeader He did not speak about the

Re: [PROPOSAL] DataModel - Improve Internal Fields injection

A big post for saying that the feature i just wanted to recall about do not fit your need :). I used it in the past for a critical audit, and was happy with it. Le 14:23 - vendredi 26 avril, Pierre Smits a écrit : > Gill, all, > > The entity_audit_log feature also sprung into my mind shortly

Re: [PROPOSAL] DataModel - Improve Internal Fields injection

Fwiw more often than not I can identify who made a specific change by searching the logs, assuming they're retained for long enough. Most http requests log the session ID (when the view is rendered) which can then be matched to a user via the Visit table. I'm not sure if that has changed in

Re: [PROPOSAL] DataModel - Improve Internal Fields injection

Gill, all, The entity_audit_log feature also sprung into my mind shortly after I posted my comment. I wonder how many of our adopters are aware of this feature and the penalty aspect in production setups. And of how many do we in this project know that these adopters are aware? Such info rarely

Re: [PROPOSAL] DataModel - Improve Internal Fields injection

Hello Pierre, If you have specific need of Auditing, after suspition of malicious users, you can enable entity_audit_log feature on the desired table. At a cost of performance loss. I do not understand why impersonation feature appears here, since it is a administrator specific feature. If an

Re: [PROPOSAL] DataModel - Improve Internal Fields injection

The two fields are extremely useful (even indispensable) regarding auditing and data analysis. Consider security assessments and fraud detection/prevention. In trunk, only 48 entities have those fields in following breakdown: Component Model Entities Having UserLogin fields % datamodel accounting

Re: [PROPOSAL] DataModel - Improve Internal Fields injection

Hello, When I worked on issue OFBIZ-5010, I have been imagine to use an other parameter on entity definition like internal to generate these 4 fields createdByUserLogin, lastModifiedByUserLogin, createdDate, lastModifiedDate. example :     but more with idea to extend it If we

Re: [PROPOSAL] DataModel - Improve Internal Fields injection

IMO, adding 'createdByUserLogin' and 'lastModifiedByUserLogin' fields to every entity is not that useful. Like for example, if we consider the "Visit" entity, I am not able to find any advantage of having these fields in this entity. But, it should be added to some crucial entities like

Re: [PROPOSAL] DataModel - Improve Internal Fields injection

Le 25/04/2019 à 14:17, Suraj Khurana a écrit : IMO, this is configurable as Jacques pointed, so need to take any action. In fact, I would suggest showing these fields while searching for any data from entity-engine in webtools, because they are really helpful while working in a dev environment

Re: [PROPOSAL] DataModel - Improve Internal Fields injection

IMO, this is configurable as Jacques pointed, so need to take any action. In fact, I would suggest showing these fields while searching for any data from entity-engine in webtools, because they are really helpful while working in a dev environment for debugging. Just my two cents !!! -- Best

Re: [PROPOSAL] DataModel - Improve Internal Fields injection

A bit out of subject, just to complete the discussion because nobody spoke about. The entities are defined with no-auto-stamp="false" by default so it's possible to change this default. Of course 'createdByUserLogin' and 'lastModifiedByUserLogin' fields are not concerned, it was just to

Re: [PROPOSAL] DataModel - Improve Internal Fields injection

I am not able to find the thread, But I remember we had already a discussion regarding the same topic. Kind Regards, Deepak Dixit On Wed, Apr 24, 2019 at 4:37 PM Michael Brohl wrote: > I have not time to elaborate in-depth right now, but just a quick food > for thought: > > Having these

Re: [PROPOSAL] DataModel - Improve Internal Fields injection

Michael, Thank you for details, all makes sense. Best Regards, -- *Rishi Solanki* | Sr Manager, Enterprise Software Development HotWax Systems Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore, M.P 452010 Linkedin: *Rishi Solanki*

Re: [PROPOSAL] DataModel - Improve Internal Fields injection

I have not time to elaborate in-depth right now, but just a quick food for thought: Having these fields in every entity *by default* allows detailed tracking of users which might be unwanted. I know that this is a sensible topic in companies and affects privacy protection. I am not sure how

Re: [PROPOSAL] DataModel - Improve Internal Fields injection

Thanks Michael, So we should keep those *TxStamp fields. But what about the second suggestion about having the 'createdByUserLogin' and 'lastModifiedByUserLogin' fields added to the internal fields set? Best regards, Pierre Smits *Apache Trafodion , Vice

Re: [PROPOSAL] DataModel - Improve Internal Fields injection

These fields are not the same, they can differ. The TX fields mark the transaction timestamp while the non TX fields mark the "real" update time. You can see it when you watch closely in the database. All changes made within an transaction have the same tx timestamp. Regards, Michael Brohl

Re: [PROPOSAL] DataModel - Improve Internal Fields injection

Dear Pierre, I'm not aware of history of this duplicate entries. I agree with you on removing duplicate fields. Also agree with adding created user and updated user fields as default. Few points for open discussion for community; - There are many entities already have user fields, so do we need

[PROPOSAL] DataModel - Improve Internal Fields injection

Hi All, Currently our functions inject following internal fields into the model of each entity: - createdStamp - createdTxStamp - lastUpdatedStamp - lastUpdatedTxStamp All of the fields above are of the field type definition 'date-time', giving for java: java.sql.Timestamp, and for