Do not update permissions or attributes if other share fields gets updated

[mrow4a]

Update share can update any field in share interface separately. This MR ensures that attributes get updated only if attribute or permission fields got updated.

• wait until 10.4.0-rc2 gets released to test manually

[codecov]

Codecov Report

Merging #313 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##             master    #313   +/-   ##
========================================
  Coverage      4.46%   4.46%           
  Complexity      306     306           
========================================
  Files            14      14           
  Lines          1188    1188           
========================================
  Hits             53      53           
  Misses         1135    1135

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3ffc162...ca61f2e. Read the comment docs.

[phil-davis]

With manual testing this looks to work nicely. Whenever "Secure view" is checked, all the other permissions are switched off (= read-only). Whenever some other permission is checked, secure view is switched off.

Rebased to trigger CI.

The workflow of the permissions checkboxes and expiration date is a bit different from what is in tests. Probably CI will fail - issue #316 I will look at adjusting the acceptance tests.

[phil-davis]

As I see it now, when a user creates a share they can share with:

1. ordinary sharing permissions and not secure-view - and then the sharee (if re-share permission was granted) can re-share just like normal. Or they can re-share with just secure-view - that is fine, secure-view is "less than read-only".

2. secure-view - the sharee gets the share, can view the document(s) in the special app that renders the document with watermark... They cannot reshare it at all (not even reshare with secure-view permissions)

As far as I can see manually this is all working fine. I just need to adjust the acceptance test scenarios to cover the above kind of things.

[phil-davis]

If we can get core PR owncloud/core#36847 merged today, then I will fix the acceptance tests here. (I don't want to bother fixing here until we at least think we have the stable solution finalized in core)

[phil-davis]

This turned out to be just a missing table headers row in the adjusted step of the failing scenario. I added a commit and it passes. I also made a core PR owncloud/core#36862 so that the test step gets our (recently) "standard" checks for this sort of problem.

[phil-davis]

WFM from a QA point-of-view.
I requested review from developers.
IMO we can merge this, then directly after 10.4 release we can also release this (and decide if we have to bump owncloud min-version="10.3" to 10.4 in appinfo/info.xml

[phil-davis]

@micbar I tagged @PVince81 for review. But request whoever you like.

[PVince81]

👍