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 modify a property with read-only permissions should fail

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

Michael Pizzo updated ODATA-941:

    Summary: Attempting to modify a property with read-only permissions should fail  (was: Attempting to specify read-only properties in update should fail if modified)

> 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

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