[OASIS Issue Tracker] (ODATA-941) Attempting to modify a property with read-only permissions should fail

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/ODATA-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62562#comment-62562 ] 

Ralf Handl commented on ODATA-941:
----------------------------------

For single-property access I can see the benefit of responding with 4xx, e.g.

   PUT Employees(4711)/Salary

should fail if the sender doesn't have permission to change this property.

For full-entity access I'd treat "no permission" identical to "read-only" to preserve easy round-tripping without having to remove properties.

> Attempting to modify a property with read-only permissions should fail
> ----------------------------------------------------------------------
>
>                 Key: ODATA-941
>                 URL: https://issues.oasis-open.org/browse/ODATA-941
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData Protocol
>    Affects Versions: V4.0_ERRATA03
>         Environment: [Proposed]
>            Reporter: Michael Pizzo
>             Fix For: V4.01_WD01
>
>
> Currently, in 11.4.3, Update an Entity, we say that "Key and other non-updatable properties, as well as dependent properties that are not tied to key properties of the principal entity, can be omitted from the request. If the request contains a value for one of these properties, the service MUST ignore that value when applying the update."
> We don't explicitly say how to handle properties that are read-write, but for which the user doesn't have permissions.  Are they considered "non-updatable" or are they considered updatable properties for which the user lacks the permission to update?
> The reason that we say read-only properties in the payload are ignored is so that a client can take what they read and write it back without having to remove certain properties. For the general case, we didn't want to burden (and slow) the service by requiring it to do a validity check on the read-only properties (type, id, etc.), and we wanted to be able to "copy" an entity by reading it and then doing a POST and having the id ignored.
> However, for cases where the user doesn't have permission to write a property it's probably wrong to return success if the final state of the property doesn't match the request. We still want the user to be able to PUT/PATCH the value they have read, without having to edit out certain values, but in this case we should probably raise an exception if the current value of the property was not the value specified by the user.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)