search

microsoft / fhir-server

A service that implements the FHIR standard
MIT License
1.19k stars 512 forks source link

Cannot create an AuditEvent resource via a PUT request #1306

Open tswelsh opened 4 years ago

tswelsh commented 4 years ago

Describe the bug To preface: this might be intended behaviour but I wanted to check. I am working on an application where we write AuditEvents to more than one place. We would like to choose the Id of the AuditEvent in the FhirServer in order to keep it consistent across the different places (i.e. use a client defined id). Although the server is configured with updateCreate = true, it rejects the PUT request for a new AuditEvent. I think this is due to the AuditEvent special case in the CapabilityStatementBuilder, combined with the upsert code path always checking for update permissions on the resource.

To Reproduce Steps to reproduce the behavior:

  1. Send a PUT request with the appropriate body to /AuditEvent/{some new id}

Expected behavior An AuditEvent with the specified id is created and 201 Created is returned.

Actual behavior The AuditEvent isn't created and a response of 405 Method Not Allowed is returned.

CaitlinV39 commented 3 years ago

@CaitlinV39 to review in Zulip

CaitlinV39 commented 3 years ago

@tswelsh we are reviewing this with the community. Right now we don't allow creates against the AuditEvent but are curious to see what other FHIR servers are doing. We'll update on a next step after we spend some time gathering feedback. You can see the chat here: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/AuditEvents.20in.20pure.20FHIR.20Servers

brendankowitz commented 3 years ago

Thanks @CaitlinV39.

@tswelsh, I think in principle it makes sense to allow a create with both PUT and POST for AuditEvent. When using PUT our system immediately checks for the update interaction on AuditEvent which fails.

My summary of the ideal behavior is this: When CapabilityStatement.rest.resource.updateCreate is true, it should allow creates on PUT and also allow modify when the update interaction (CapabilityStatement.rest.resource.interaction) is also present.

tswelsh commented 3 years ago

Thanks for looking into this! To be clear, our desired behaviour would be to create AuditEvents with a PUT request but not allow editing or deleting, which sounds like something we could do if it matches your ideal behaviour.

CaitlinV39 commented 3 years ago

AB#77959