API updates vs. profile locks and Revisions (to revert changes)

(this is 'public' discussion thread)

Sorry a little bit off topic, but may be related?

Could it be the API has some more rights than the user has?
I got some information from the SmartCopy check that mentioned the names and some other data from a private profile where all I could see was <private>. It offered a fix but that got an error because it could not access the profile for updating.

Mike Stangel wrote: (https://www.geni.com/discussions/172419?msg=1172798)
"Should we make the API force you to pass a key to unlock the fields you want to edit? I doubt anyone would make good use of such a change"

If there were such a feature added (that the default would be to not allow over-riding of locks unless an additional "token" were passed), I could see that SmartCopy could be enhanced to use that feature ... perhaps in this way:

The default would be to not over-ride the lock, but if the Curator-user clicked on the "lock-icon" in the SmartCopy panel, that would set (add) that over-ride "token" to that particular field ... that would prevent accidental over-riding of locked fields by forcing the Curator to "open the details" and to explicitly select individual fields to over-ride.

That "over-ride token" could even be one that Geni has to grant to the application ...

However: Two additional factors come to mind:

1) If the Revisions accurately reflected API changes, then I see less need for preventing Curator over-ride (by default).

2) If the Geni-based "unlock-edit-lock" is truly fixed now, there is less reason to want to have the convenience of SmartCopy (or other API-driven updates) to update locked fields. (Which argues for no over-ride via API at all ... but I really hesitate to remove completely such a potentially useful capability from future Apps, such as one to "standardize" location fields based on the dates in the profile and some future database of historical locations, for example.)

Job: That is exactly the way it should work as far as updating. What may be a 'API bug' is that you could even see (retrieve) that information in the first place via SmartCopy.

Could you start a new API discussion with specific examples of that? It "feels like" a different topic ...

Dan, oke I will do that when I see a new example (not sure where I saw this)

Here is an example of Revisions not (currently) showing API updates:

Walter Row

From the 'references', Walter was first added as a "father" with a birth date of 1889 (just the year).
Roughly 35 minutes later, another reference had a precise birth date (12/8/1888).

The Revisions list does not show that. If that detail had gone the other way (from precise date to just a year), there would not be a way to "recover" it (short of remembering there was a precise date and checking each 'link' added by SmartCopy).

Mike Stangel

Genealogy is actually a data management discipline, and traceability is key for it. Losing track of changes is a killer and actually the effort to secure the traceability is not really big.

I think all changes shall be tracked, acutally I do not like the current information about the information detail about changes.

Thanks Dan Cornett this is very disconcerting. We've identified the problem and released a fix, but unfortunately it's not possible to backfill the missing revisions.

I didn't expect that you'd be able to "back fill"; I'll continue to check on the API updates getting logged, and post specifics if I see any.