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

Refactor to separate app code logic from core groups/memb logic + keep groups always in sync for centr_groups feature #138

Closed
wants to merge 2 commits into from

Conversation

mrow4a
Copy link

@mrow4a mrow4a commented Mar 8, 2018

The goal of following changes were to:

Refactor:

  • App code is only to serve user interface, and all interaction with core is through custom group manager (CustomGroupManager class) and GroupInterface (group backend). No DAV (user interface related) component should ever call CORE directly.

Always sync with centr_groups:

  • App keeps its groups/memberbers in sync with core with any action in the UX (add group/user remove group/user)

  • Central groups in core will result in separate core groups/membership logic so that core never hits the app code (and thus core is more stable)

  • Manual checks passed with stable10 in core

  • Manual checks passed with centr_groups in core

  • Adjusted unit tests

@CLAassistant
Copy link

CLAassistant commented Mar 8, 2018

CLA assistant check
All committers have signed the CLA.

if (is_null($groupInfo)) {
// TODO makes no sense, l10n does not exist here..
Copy link
Author

Choose a reason for hiding this comment

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

Should I add l10n?

@@ -92,19 +85,21 @@ public function index() {
/**
* Search in all groups the current user is member of
*
* @param string $customGroupId custom group id
* TODO: Get explanation what this was supposed to do
Copy link
Author

Choose a reason for hiding this comment

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

I have no idea what is this function about

@@ -47,42 +46,13 @@ public function __construct(
}

/**
* Checks if backend implements actions.
* Expose to the core only group details
Copy link
Author

Choose a reason for hiding this comment

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

This backend exposes to core only groupDetails

* @param string $gid gid of the group
* @return boolean true if user is in group, false otherwise
*/
public function inGroup($uid, $gid) {
Copy link
Author

@mrow4a mrow4a Mar 8, 2018

Choose a reason for hiding this comment

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

all memberships in this backend are gone to core - only groups are kept for consistency.

@mrow4a mrow4a changed the title [WIP] Adjust custom groups to central group table Separate app code logic from core groups/memb logic + keep groups always in sync Mar 15, 2018
@mrow4a
Copy link
Author

mrow4a commented Mar 15, 2018

Hey @IljaN @PVince81 could I have comments on the justification of change and review of the code? I updated the description

Thanks!

throw new NotFound("Group not found \"$groupId\"");
}
$group->delete();
$this->helper->deleteGroup($uri);
Copy link
Author

Choose a reason for hiding this comment

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

Moved the delete group logic to Helper (which does the sync to core also)


$event = new GenericEvent(null, ['groupName' => $this->groupInfo['display_name'], 'user' => $userId]);
$this->dispatcher->dispatch('\OCA\CustomGroups::addUserToGroup', $event);
$this->helper->addUser($this->groupInfo['uri'], $userId);
Copy link
Author

Choose a reason for hiding this comment

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

Moved the add user to group logic to Helper (which does the sync to core also)

if (!$this->helper->isUserAdmin($this->groupInfo['group_id'])) {
return 403;
}
$result = $this->helper->updateGroup($this->groupInfo['uri'], $displayName);
Copy link
Author

Choose a reason for hiding this comment

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

Moved the group update logic to Helper (which does the sync to core also)


// add current user as admin
$this->groupsHandler->addToGroup($this->helper->getUserId(), $groupId, true);
$this->helper->createGroup($name, $displayName);
Copy link
Author

Choose a reason for hiding this comment

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

Moved the group create logic to Helper (which does the sync to core also)

$event = new GenericEvent(null, ['userId' => $userId, 'groupName' => $this->groupInfo['display_name']]);
$this->dispatcher->dispatch('\OCA\CustomGroups::leaveFromGroup', $event);
}
$this->helper->removeUser($this->groupInfo['uri'], $this->memberInfo['user_id']);
Copy link
Author

Choose a reason for hiding this comment

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

Moved the add group user logic to Helper (which does the sync to core also)

@mrow4a
Copy link
Author

mrow4a commented Mar 15, 2018

Keep note that I also keep custom groups and memberships table - this is to not affect negatively stability of the app with big rewrite (with core mem/groups being new), and additionaly for consistency so if something goes really wrong, some cronjob sync will adjust it back (source of truth is custom groups app).

Copy link
Contributor

@IljaN IljaN left a comment

Choose a reason for hiding this comment

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

👍 for code-style. I don`t have enough knowledge in this part of core to do a full review. So only a nitpick:

If possible and in the scope of this task try to decompose the Helper class (ideally remove it) and fit the methods somewhere else in the architecture (maybe in smaller specialized classes) . Or if a helper method is just used once move it to a private method of the using class.

In my experience helper classes tend to accumulate all kinds of cruft, especially in bigger projects and finally transform to dumps for methods when people are in a hurry or don`t understand the architecture.

https://rrees.me/2009/02/09/the-helper-anti-pattern/
https://en.wikipedia.org/wiki/God_object

@PVince81
Copy link
Contributor

Mind pointing to the changes you did after moving the code ? Another alternative is to have the first PR commit only move the code and the second commit make the change so we can clearly see it. When moving code + changing it is difficult to see what's changed.

Will this code also work with previous 10.0 versions ?

@mrow4a
Copy link
Author

mrow4a commented Mar 16, 2018

@PVince81 Good idea! Will do :>

Yes. it will work only with central_groups branch. However, without this change custom groups will also work, but users will see their memberships and new groups on login or when sync cron runs.

So yes, this PR in case of custom groups is required, since it is OC user creating groups, not LDAP admin.

@mrow4a mrow4a changed the title Separate app code logic from core groups/memb logic + keep groups always in sync Refactor to separate app code logic from core groups/memb logic + keep groups always in sync for centr_groups feature Mar 30, 2018
@codecov-io
Copy link

codecov-io commented Mar 30, 2018

Codecov Report

Merging #138 into master will increase coverage by 1.3%.
The diff coverage is 99.13%.

Impacted file tree graph

@@             Coverage Diff             @@
##             master     #138     +/-   ##
===========================================
+ Coverage     83.61%   84.92%   +1.3%     
- Complexity      300      306      +6     
===========================================
  Files            21       22      +1     
  Lines           952      975     +23     
===========================================
+ Hits            796      828     +32     
+ Misses          156      147      -9
Impacted Files Coverage Δ Complexity Δ
lib/CustomGroupsDatabaseHandler.php 92.48% <100%> (-0.17%) 32 <2> (-2)
lib/Controller/PageController.php 90% <100%> (+0.11%) 32 <0> (ø) ⬇️
lib/Dav/MembershipNode.php 96.36% <100%> (-0.66%) 24 <0> (-2)
lib/Dav/UsersCollection.php 93.93% <100%> (ø) 14 <0> (ø) ⬇️
lib/Dav/GroupsCollection.php 100% <100%> (+1.58%) 23 <0> (ø) ⬇️
lib/Dav/GroupMembershipCollection.php 97.53% <100%> (+0.65%) 39 <0> (-1) ⬇️
lib/Service/Helper.php 100% <100%> (ø) 26 <2> (?)
lib/CustomGroupsBackend.php 91.22% <100%> (+8.97%) 21 <4> (-3) ⬇️
lib/SettingsPanel.php 100% <100%> (ø) 4 <1> (ø) ⬇️
lib/Dav/RootCollection.php 100% <100%> (ø) 1 <0> (ø) ⬇️
... and 3 more

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 5daa016...8b19bf5. Read the comment docs.

@mrow4a
Copy link
Author

mrow4a commented Mar 30, 2018

@PVince81 @IljaN @tomneedham @butonic Just tested this app both with unit testss (>90% coverage) and manualy for stable10 core with 1st commit. This refactor should make this app cleaner, @IljaN thanks for earlier comments, they were very helpful - now there is a class CustomGroupsManager.

@mrow4a
Copy link
Author

mrow4a commented Mar 30, 2018

Yes, after change in first commit, this app will work with both central groups and with earlier versions. This is due to the fact I really separated this app from core.. the only difference with central_groups is that instead core hitting this app for groups (through GroupInterface), it will not touch it and use central groups table. On other hand, app will sync all its changes with core (except admin of custom groups, since core does not care and this is only UX feature) @PVince81 @DeepDiver1975

@@ -37,7 +37,7 @@ Sharing with a Custom Group is as easy and quick as always. Just click on the sh
</types>
<use-migrations>true</use-migrations>
<dependencies>
<owncloud min-version="10.0.3" max-version="10.1" />
<owncloud min-version="10.1" max-version="10.1" />
Copy link
Author

Choose a reason for hiding this comment

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

@PVince81 ok, with second commit I needed to increase the requirement, since createGroupFromBackend is needed for syncing with core. Everything else works as previously.

Copy link
Author

Choose a reason for hiding this comment

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

First commit however passed all checks with stable core

@mrow4a
Copy link
Author

mrow4a commented Jan 14, 2020

central group tables wont be done

@mrow4a mrow4a closed this Jan 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants