Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add exclude_groups_from_sharing to capabilities #31580

Merged
merged 1 commit into from
Jun 28, 2018

Conversation

phil-davis
Copy link
Contributor

@phil-davis phil-davis commented May 29, 2018

Description

In the capabilities API response, files_sharing section, add:

exclude_groups_from_sharing => boolean state of this setting
groups_excluded_from_sharing => array of groups that are excluded from sharing

and only report this if the user is an admin.

In the capabilities API response, files_sharing section, add:

can_share => boolean state of this setting

Set to true if the user requesting the capabilities can do sharing (i.e. the sharing API is enabled and the user is not excluded from sharing). Otherwise set to ``false```.
This capability could be used by a client app to, for example, decide if the client app should bother to display UI elements for adding shares...

Related Issue

#31576

Motivation and Context

The setting of "exclude groups from sharing and the list of groups that are excluded is not in the capabilities API response.

How Has This Been Tested?

Local API test runs, and browsing to the capabilities URL.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

@codecov
Copy link

codecov bot commented May 30, 2018

Codecov Report

Merging #31580 into master will decrease coverage by <.01%.
The diff coverage is 55.55%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master   #31580      +/-   ##
============================================
- Coverage     63.27%   63.26%   -0.01%     
- Complexity    18479    18483       +4     
============================================
  Files          1161     1161              
  Lines         69377    69386       +9     
  Branches       1261     1261              
============================================
+ Hits          43895    43900       +5     
- Misses        25112    25116       +4     
  Partials        370      370
Flag Coverage Δ Complexity Δ
#javascript 52.47% <ø> (ø) 0 <ø> (ø) ⬇️
#phpunit 64.5% <55.55%> (-0.01%) 18483 <2> (+4)
Impacted Files Coverage Δ Complexity Δ
apps/files_sharing/lib/Capabilities.php 92.42% <55.55%> (-5.83%) 13 <2> (+4)

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 7549002...13dac01. Read the comment docs.

@phil-davis phil-davis force-pushed the exclude_groups_from_sharing-capability branch from d5299d0 to 9fb33f0 Compare May 30, 2018 07:47
| files_sharing | groups_excluded_from_sharing@@@element[1] |
| files_sharing | groups_excluded_from_sharing@@@element[2] |

@skip @issue-enterprise-2508
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This scenario should be fixed by #31490 - so when/if this PR is merged, this skip line can be removed in that PR.

@phil-davis phil-davis force-pushed the exclude_groups_from_sharing-capability branch from 9fb33f0 to 3fd24df Compare May 30, 2018 12:49
@phil-davis
Copy link
Contributor Author

phil-davis commented May 30, 2018

@PVince81 please have a look and see if I have done reasonable stuff here. I am not familiar with exactly how the DI should be done to get hold of the user and group classes so as to work out if the user is an admin. But this code does work.

@@ -103,6 +131,20 @@ public function getCapabilities() {
$res['share_with_group_members_only'] = $this->config->getAppValue('core', 'shareapi_only_share_with_group_members', 'yes') === 'yes';
$res['share_with_membership_groups_only'] = $this->config->getAppValue('core', 'shareapi_only_share_with_membership_groups', 'yes') === 'yes';

if ($this->isAdmin()) {
$res['exclude_groups_from_sharing'] = $this->config->getAppValue('core', 'shareapi_exclude_groups', 'yes') === 'yes';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in general admins already have access to the config APIs and would be able to retrieve the value from there (which the settings page does), so not sure we really need that in the capabilities for admins

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what to do?
do I look somewhere in "config APIs" to get these settings during acceptance test scenarios?
do I remove the code here?
(which will leave just the calculation of can_share which was just a bonus when I started this)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, the "config APIs" are likely a private endpoint... see https://github.com/owncloud/core/blob/v10.0.8/core/js/config.js#L11

We'll likely need to expose those private APIs using public API format (OCS or Webdav)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@phil-davis any reason you need to read any detailed config values during tests ? you could simply set the value to something known so you know it's set during test setup as part of the prerequisite ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, we do not have to read back the values. It was just that for other "system/app settings" (at least the ones we used so far), the current setting could be found in capabilities. So I was just maintaining consistency.
We can let the tests make the settings and then the next test steps will observe the changed behavior. If the behavior does not change then either the setting change failed or theere is a bug in the behavior.

@PVince81
Copy link
Contributor

PVince81 commented Jun 1, 2018

The DI looks ok.

See my comment about the admin part.

@PVince81
Copy link
Contributor

I'd rather not expose this setting if there is no need for clients to know this information, considering that it's conditional. So it's not really a capability any more as it depends on the logged in user.

I see you added some utility functions for tests, maybe we could keep those though?

@phil-davis
Copy link
Contributor Author

rather not expose this setting

which setting do you mean:
can_share - it is conditional, value depends on the logged in user (a capability with-respect-to the current user)
or
exclude_groups_from_sharing - reporting of the "capability" is conditional, depends on the logged in user having admin rights.
?

@phil-davis
Copy link
Contributor Author

I will look through and separate out useful acceptance test stuff related to processing lists in returned xml - that will be good for other stuff in capabilities and... that can have more/better tests.

@PVince81
Copy link
Contributor

I meant not exposing "exclude_groups_from_sharing". we can keep "can_share"

@phil-davis phil-davis force-pushed the exclude_groups_from_sharing-capability branch from fcb267e to e39b0cd Compare June 22, 2018 03:25
@phil-davis phil-davis force-pushed the exclude_groups_from_sharing-capability branch from e39b0cd to 13dac01 Compare June 22, 2018 03:38
@phil-davis
Copy link
Contributor Author

phil-davis commented Jun 22, 2018

I rebased this to sit on top of the can_share changes that are now in master - just so that the exclude_groups_from_sharing code is still here. Probably will not be used.

Copy link
Contributor

@PVince81 PVince81 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@PVince81 PVince81 merged commit 24411c1 into master Jun 28, 2018
@PVince81 PVince81 deleted the exclude_groups_from_sharing-capability branch June 28, 2018 10:13
@PVince81
Copy link
Contributor

backport?

@phil-davis
Copy link
Contributor Author

phil-davis commented Jun 28, 2018

@PVince81 the can_share capability was separated into a different PR #31816 which is merged and good.

This PR here is the remaining code, which reports the exclude_groups_from_sharing setting in the capabilities, only if the caller has admin privs. If the Boolean setting is on, then it also reports groups_excluded_from_sharing

I didn't think that you wanted to add this stuff to the capabilities report?

But I am very happy to have it available - it will make tests flow easily.

@PVince81
Copy link
Contributor

I didn't. When I saw the PR I thought it was the updated version where this one was removed already without looking more closely.

Reverting...

@PVince81
Copy link
Contributor

revert PR here #31937

@phil-davis
Copy link
Contributor Author

This part is not being implemented. Backport request removed.

@lock
Copy link

lock bot commented Jul 30, 2019

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.

@lock lock bot locked as resolved and limited conversation to collaborators Jul 30, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants