Stream: implementers
Topic: Historical entry operations
Grahame Grieve (Jun 13 2018 at 23:06):
regarding GF#17258, I believe that we've agreed to remove the $meta-add/$meta-delete operations applicabilityto history entries from the spec. Is this other people's memory (@Ewout Kramer @Lloyd McKenzie @Josh Mandel )?
Lloyd McKenzie (Jun 13 2018 at 23:18):
It's in my memory because I was told it was happening, but not because I was part of the decision. If we're going to do that, what our expectations about security tags with respect to historical versions? Tags of the current version apply to all versions? (And be aware that access to the current version will (for most tags) also grant access to historical versions?)
Ewout Kramer (Jul 02 2018 at 09:24):
Yes, this has come up a few times now. I am all for removing it from the spec, it adds complexity and I have not heard strong usecases. Since the history is mostly there for auditing purposes (not for tracking actual medical developments in the patient), changing history does not sit well with me.
Brian Postlethwaite (Jul 04 2018 at 06:46):
Access control to the historical versions is the only reason here for me.
Lloyd McKenzie (Jul 04 2018 at 13:08):
So the base questions are: Does anyone need the access control to a historical version to be different from that for the current version?; and are we comfortable that when you process a GET for a historical version you always have to grab the access control information from the current version to decide whether to expose that historical version?
John Moehrke (Jul 05 2018 at 14:13):
The only use-case that comes up is where someone HAD access to the historic, but is now forbidden access to current. They should be denied on request for current, but might be allowed to access the old version that the had access to at one time. This is an edge case, that is also potentially dangerous. Thus I am not going to advocate that it be supported.
The reverse might be considered, where only current version is accessible, but not historic (because they are not valid).... this likely is done for all resources, not a specific instance.
That said, the Consent resource can point at a version specific instance...
Grahame Grieve (Jul 05 2018 at 19:10):
actually, the use case is where you change your mind about access to specific history entries in either direction (permit | deny)
Last updated: Apr 12 2022 at 19:14 UTC
