OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (ODATA-941) Attempting to specify read-only properties in update should fail if modified


Michael Pizzo created ODATA-941:
-----------------------------------

             Summary: Attempting to specify read-only properties in update should fail if modified
                 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)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]