[Feature Request] Propagate mount write/update permissions to the client

[mmattel]

Realted to:
#29873 ([Feature Request] Mark mount as read only in the mount settings)
owncloud/client#6252 ([Feature Request] Define actions on read only mounts)

We should let the client proactively know which rights the mount has to properly define actions on.
Especially that the client can not write back (is_creatable, is_updatable).
We already have mounts where you can read only (ro-share).

Without propagating this, the client thinks he can write back and fails.
The user is confused as he has no clue or forgotten why this is the case.

An implementation would enable the client to define actions based on this info.

@PVince81 @SamuAlfageme

[ownclouders]

GitMate.io thinks the contributor most likely able to help you is @PVince81.

[SamuAlfageme]

One more use-case to WebSockets -> owncloud/client#6195

[PVince81]

Most is already in place: there's an oc:permissions Webdav attribute that clients likely already use when dealing with received shares and read-only status. What we need to do however is find a way for storages to provide said read-only information when technically possible. And as a fallback, allow the admin to tag a mount as read-only as per #29873. Doing so would simply return read-only permissions through all the APIs and also through oc:permissions.

I'd vote for closing this ticket in favor of #29873 as we don't need any extra attributes or APIs.

[mmattel]

Question, just don´t know it:
The oc:permissions Webdav attribute is already handed over to the client as part of the mount info?
If this is the case, we can close this issue, because then it is just upon the client to use the attribute.

Addon question: which states can oc:permissions have ?

[PVince81]

@mmattel "oc:permissions" is fetched and used by the client in general, not only for mounts.

[mmattel]

@PVince81 Thanks for clarification
From my POV, we can close this ticket as suggested and continue in #29873.

[SamuAlfageme]

@mmattel yup, like @PVince81 said oc:permissions are requested as part of the client's PROPFIND

  <d:response>
    <d:href>/remote.php/dav/files/admin/ownCloud/</d:href>
    <d:propstat>
      <d:prop>
        <d:resourcetype>
          <d:collection/>
        </d:resourcetype>
        <oc:size>678556</oc:size>
        <oc:permissions>RMCK</oc:permissions>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
  </d:response>

You can check all the values the permissions mask can have in https://doc.owncloud.org/desktop/2.4/architecture.html#server-side-permissions (and the Sabre connector equivalent in https://github.com/owncloud/core/blob/master/apps/dav/lib/Connector/Sabre/Node.php#L317-L347)

An example on how the client uses these would be how the M (the "mount" one actually) value to trigger confirmation for received mountpoints; see: owncloud/client#5340

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.