RESOStandards / transport

RESO Transport Workgroup - Specifications and Change Proposals
https://transport.reso.org
Other
18 stars 15 forks source link

Record level restrictions #47

Closed codygustafson closed 1 year ago

codygustafson commented 1 year ago

FBS has needed the functionality in the past to differentiate between null values and a restricted values for a particular listing record. This is in regards to fields that have permissions based on the record you are viewing. As an example: If a developer is accessing the API on behalf of an agent and that agent does not have access to view the ExpirationDate in a different office, It should be displayed as a permissions issue. "null" is not the same thing since it indicates there is no value. In this case, there is a value but the authorized user of the API does not have permission to see it.

FBS has adopted Core.Permissions to handle this use case for our members. In the past, I believed this was fine since it is part of the OData spec. But now that we would like to start being strict with metadata and which fields display on a listing.

Properties that are not available, for example due to permissions, are not returned. 

This may contradict some of the previous testing we discussed about metadata strictness. I would like to officially support this functionality within RESO. If there is another way to show this data as restricted, I'm all ears. I'm not particularly a fan of this method but since it was the OData definition I found and it fit our use case, we implemented it.

codygustafson commented 1 year ago

See discussion https://github.com/RESOStandards/transport/discussions/51

darnjo commented 1 year ago

Closing for now. We can reopen depending on the outcome of the related discussion.