-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
replaceTo is not appropriate for MHD #192
Comments
Note also that this feature was added to master branch, it does not only exist in Improvements branch. |
@JohnMoehrke where do you see this feature added to the master branch? all the PR is see are against the improvements brach as far as i have seen. replaceTo has nothing to to with Metadata Update or Restricted Update but is the equivalent to Document Replace in XDS |
discussed on ITI meeting: This is limited to support needed for Replace normal behavior, as the Document Source does need to change only the relationship of the old to the new. Action: John to update ex-ProvideBundles3.fsh, line 154 to use the profile name. Action: John to update release note to indicate that there is a PATCH function to support replace Action: John to add open-issue, asking for feedback on this PATCH function for replace used to set the status element of the old DocumentReference to superseded. in section 2:3.65.4.1.2.3 Replace, Transform, Signs, and Append Associations, new responsibility added : "If a DocumentReference will be replaced, the to be replaced DocumentReference needs to be added and updated to status superseded within the transaction bundle." |
added open issue MHD_068 - #197 |
I was not aware that the 'replaceTo' behavior that was added. It was not clear to me that that this enabled changing of DocumentReference.
This is not consistent with Document Sharing core functionality that does not allow changing of a DocumentReference/DocumentEntity once it is submitted; with the exception of the administrative implementation guides like Metadata Update and Restricted Update. These administrative Profiles are not core.
As with Metadata Update, this should be only allowed with special administrative rights.
I do not agree that this is part of the Improvements Branch. I am sorry that I am only now noticing that this was merged without review.
If it is added, it MUST be added inside of a named Option; which this is not enclosed in a named option. This is both a requirement of our Improvements branch methodology, and also would make it clear that it is optional and that when enabled would be presenting additional security challanges.
The text was updated successfully, but these errors were encountered: