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.
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.
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.