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 recent versions but I've used it many times over the years. Regards Scott On Sat, 27 Apr 2019, 00:23 Pierre Smits, <pierresm...@apache.org> wrote: > 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 trickles back into our mailing lists. > Even in this community there hasn't been much traffic regarding that > subject over the years. Markmail (see [1]) revealed that they have only > just over a 100 postings registered. > > And isn't so, that when an adopter suspects foul play this often already > has happened. Enabling the entity_audit_log feature after suspicion of foul > play is like closing the barn after the horse has beens stolen. > > But lets address the 'what is required to have the entity_audit_log-feature > operational' for a moment. > I did a google search on the subject and I found nothing (substantial) > about this feature that explains how it functions and what is required to > have it operational. > From what I got from memory recollection and recent searches, that this > only works for fields that have the 'enable-audit-log' attribute set to > "true" in the entity-models. I found only 10 fields in the various > applications component have such an attribute setting (only 2 entities in > order-entity.model: OrderItem and ReturnItem . Non of the other fields in > the entity models have have the 'enable-audit-log' set to 'false'. > > And you are correct, this feature comes with a processing penalty, which > increases with the number of fields marked for auditing. That is the first > -1 about having to do analysis on who created and changed what, where and > when. > > The second -1 about the 'enable_audit_log'-feature is that, even when an > adopter is having the 'audit' and the entity_audit_log feature on his mind > and wants it operational for more business critical fields in then his > implementation project will increase as all the entities need to be > enhanced regarding those fields. Plus in this feature for audit trails and > fraud detection it requires fields that capture the UserLogin values > (createdBy and lastModifiedBy). In current code base even less entity have > a field that captures the userLogin (12, through the changeByUserLoginId > field). > > The third -1 is that this feature doesn't appear have a property setting to > enable or disable the feature in underlying services. That means it is > always on, and dependent on the entity-model changes. When the adopter > suspects foul play he can't simply change a property setting to temporarily > take the performance penalty to confirm or debunk his suspicion. Nor does > he have functionalities available to enable/disable specific fields > dynamically through the UI (of e.g. web tools). > > And last but not least: he fourth -1 regarding the > 'enable_audit_log'-feature is that it doesn't appear to be working as > expected. I did a cursory test with an order some moments ago in ofbiz (see > [1]) and it does not capture the old values on the line items. But I may be > misunderstanding the screen/process there. > > All in all, there are a lot of technical +1s in favour of having the > createdByUserlogin and lastModifiedByUserLogin added through the internal > fields injection process. The implementation in the code base by the > community can be achieved fairly fast. The impact on migration (for > existing adopters planning to upgrade) is rather small, as it only extends > the model with 2 fields (added at the end) and easily explained. And it > offers additional business-case benefits for those considering to use the > product for their mission critical business processes. > > [1] > > https://ofbiz.markmail.org/search/?q=enable-audit-log#query:enable-audit-log+page:1+state:facets > > Best regards, > > Pierre Smits > > *Apache Trafodion <https://trafodion.apache.org>, Vice President* > *Apache Directory <https://directory.apache.org>, PMC Member* > Apache Incubator <https://incubator.apache.org>, committer > *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges) > since 2008* > Apache Steve <https://steve.apache.org>, committer > > > On Fri, Apr 26, 2019 at 12:17 PM Gil Portenseigne < > gil.portensei...@nereide.fr> wrote: > > > 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 admin is malicious, having those > > fields cannot prevent him to destroy/modify/create or do whatever with > > the data. > > > > Like you can guess, my opinion, is not to put those fields onto all > > entity in OFBiz. > > > > I agree that security is important, and OFBiz admin must grant the good > > permission to the trusted users. > > > > If you find out that specific entity miss those fields, it can be added > > case by case. But i do not feel ok into a global feature. > > > > Regards > > > > Gil > > > > >
