Sad, sad. But I don't know that it is correct to say that because a concept name has changed (or been added or deleted) that the concept has changed. Because we added "Sí" as the Spanish version of the "Yes" concept, have we really changed the concept? Especially now that we are coming at concepts from the other direction (concept source, concept map), the addition of the name used in that source shouldn't amount to a change the concept.
I don't know that there is a general rule we can apply to decide whether a child collection is really a field of the parent and therefore a change to the parent should be audited, or whether the child is an independent object that should be audited separately from the parent. Ben, from your current perspective, everything looks like the first case, but as the parent of a 20 year old, things look really like the second case. It does seem clear that where we have a proper subclass, or a subclass implemented by a "has-a" relationship, the parent should definitely be audited (and if we have a proper subclass, the child won't even have the audit fields). From: [email protected] [mailto:[email protected]] On Behalf Of Ben Wolfe Sent: Wednesday, March 28, 2012 1:48 PM To: [email protected] Subject: Re: [OPENMRS-DEV] Audit info not getting set when associations are edited It only has to be on objects that have child collections. The sad part is we've come full circle. :-/ 1) Put calls to setChangedBy in service save methods (like ConcpetServiceImpl.saveConcept(Concept)) 2) Moved calls to more central AuditableSaveHandler 3) Realized that save handler set changed by on all child objects, so create AuditableInterceptor to only set it on objects with modifications 4) Realized that the interceptor doesn't work for parent objects and put hte save back in the service methods. :-( Ben On Wed, Mar 28, 2012 at 9:28 AM, Wyclif Luyima <[email protected]<mailto:[email protected]>> wrote: If it turns out that we have to manually do this from the save method, it means we would have to do the same for all other domain objects when saving them since this is happening to all. Wyclif On Wed, Mar 28, 2012 at 8:49 AM, Ben Wolfe <[email protected]<mailto:[email protected]>> wrote: I assume this is happening because of our switch to using the AuditableInterceptor class to set the changed by. https://tickets.openmrs.org/browse/TRUNK-1930 If I add a new mapping to a concept or edit the answers of a concept, that is changing the concept. The concept.changed_by should be updated. If we can't detect and set that from the AuditableInterceptor, we'll have to manually set that from the ConceptService.saveConcept again. :-/ Ben On Tue, Mar 27, 2012 at 5:31 PM, Wyclif Luyima <[email protected]<mailto:[email protected]>> wrote: Actually for trunk, The issue shows up if you edit an element in a collection, for the others, it does change. Wyclif On Tue, Mar 27, 2012 at 5:17 PM, Wyclif Luyima <[email protected]<mailto:[email protected]>> wrote: Hi, Looks like audit info doesn't change for an edited object if the change has actually happened an associated/child object e.g if i add/remove/edit a concept name for a concept, the concept's audit info doesn't change but i believe the one for the concept name does change. Is this the behavior we expected? i.e if i edit any object, should the owning object's audit info change too, this is related to this ticket TRUNK-3051 Wyclif ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
