We have noticed in Specify 7 (v7.12.0.6) that only certain fields will change the ‘Last Edited By’ agent within a collection object. We’ve learned that changing the ‘Accession’, ‘Taxon’, ‘Verbatim Locality’, ‘Date’, or ‘Det by’ fields will not change the ‘Last Edited by’ agent. Is this a bug, or will only certain fields trigger an agent change?
Hi @vanessadelnavaz,
Hm, we could not recreate this behavior on the demo fish database or a local copy of the sbnhmiz database.
Are you still experiencing this issue? If so, could you please share a screen recording of this happening?
Thanks in advance!
@vanessadelnavaz This is a feature, not a bug, so to speak! It’s a design flaw endemic to Specify’s relational data model. I have noticed this as well and don’t like it. 
The problem you’re describing is that the ModifiedByAgent and timeStampModified (or in your case, “Last Edited By” fields) only apply to changes to fields in the base table of the subform you’re currently viewing, in this example, the Collection Object form.
When you edit Locality or Determination fields in subforms embedded within the Collection Object form (or any fields displayed in subforms on another table’s base form), what you’re doing is modifying those tables, not the Collection Object table. So the Modified fields that are displayed at the bottom of a form remains unchanged.
It’s only when you edit something like Collection Object Remarks or Catalog Number that Collection Object - ModifiedBy and Collection Object - timestampModified will change.
This is a problem, because most users, like you, (and myself, before I realized this is how it worked), would intuitively assume that Collection Object - ModifiedByAgent or Collection Object - timeStampModified will update when any data that displays in the Collection Object form view is modified. The unfortunate thing is that almost all of the frequently modified and important fields displayed on Collection Object form views are not actually stored in the Collection Object table.
It is tough for me to imagine what the proper solution to this problem is, because on the one hand, it is important to keep each individual tables’ modified timestamps and agents separate for auditing purposes, but in many cases (like displaying at the bottom of a form view that includes many tables that are editable from that view) the most recent of the entire set of these Modified fields should display, not just the one for the base table.
An additional problem is that the dwc:Modified term that many collections map their Collection Object - timeStampModified field to is not synonymous with any one Specify table’s timeStampModified field, but rather is synonymous with “the most recent of the set of timeStampModified for all records in all tables that comprise a single record”. But some collections may interpret modifications differently. For example, if I commit a change to the parent record of a geography record but that geography parent doesn’t display in the CO form, did I really modify that record?
@bronwyn A configurable virtual field with the most recent timeStampModified of certain fields/tables might be a nice way to solve this issue for the GUI, but it wouldn’t solve the DarwinCore export problem.
Thank you @nfshoobs for your reply!
I see your point now that if only the embedded record is saved, the timestampModified on Collection Object is not affected.
When edits to related/embedded records are modified, it enables the save button on both the related record and the base/Collection Object record. Clicking Save on both records will update timestampModified on the Collection Object record as you’re expecting.
This workflow should clear up the in-Specify and data exporting concerns. 
Also, a section with the timestampModified fields from related records on the CO form is possible using dot notation in the name attribute (e.g., name="collectionObject.collectingEvent.Locality.timestampModified". I image it would take up a bit of space on the form, though.