[Marketplace] Permissions should be settable by placing a user into a predefined group

[spencern]

Permission groups should exist.

Users should be able to be placed in multiple groups. Groups should be able to cascade in some way. Perhaps Permission Groups should be able to inherit permissions from other groups as well.

By placing a user into a permission group, said user should be granted all permissions that are defined in that group for the specific shop context that was granted

By removing a user from a permission group, all permissions defined in that group - that are not available in some other group the user is in - should be revoked from that user.

If a user's permissions are customized by an admin, the user should be removed from any groups associated with a specific set of permissions and re-granted individual permissions that match the customized set of permissions they now have. The user should no longer be associated with a Permission Group in the Accounts dashboard but should instead be labeled as having a Custom Permissions set in the Accounts dashboard. Multiple users with Custom Permissions may be grouped together, but should not be assumed to have similar permission sets.

Possible Default Permission Groups

• Marketplace Owner
• Marketplace admin
• Shop Owner
• Shop Admin
• Affiliate Shop Owner
• Affiliate Shop Admin
• Customer
• Guest

[spencern]

#372 has some old discussion around groups.

[impactmass]

Branch: Link
WIP PR: #2448

Todos:

• Creating a group permission
• Updating a group permission and updating users belonging to that group
• Adding a user to a group
• Removing a user from a group
• Tests

[impactmass]

Update:
_ Group methods completed
_ Not all the group methods I've written can be tested from the UI yet... So, still keeping the WIP label on the PR.

_ But feedback can be given on this file: server/methods/core/groups.js. As it contains the main work.
... I added comments to explain some parts.

_ Next steps:
Implement design from Ryan (as it relates to groups), and connect them to the methods. At that point, the whole groups PR can be tested.

[impactmass]

*Status:
_ I'm working on adding more tests for the group methods
_ and also adding email notification
_ while @rhenshaw56 is working on UI for accounts dashboard (part of which the groups methods will be used with)

[impactmass]

I was out for 2 days so there's been no update here. Here's the current status:
_ I've written tests for group methods (can be seen in methods/core/groups.app-test.js
_ The tests covered group/createGroup, group/addUser, group/removeUser
_ There's a new discussion on my PR (#2448) about the Groups schema on Accounts to use object-style of saving data instead of Array of objects.
_ I'll be checking to see if that methods works better than the array style that I currently have (I have a vague recollection of trying out the object style and hitting a block. I'll check again & update after)

[impactmass]

I'm basically done with the implementation change I mentioned in the last comment. I've update the PR.

The only issue on the PR is that some other tests (outside of the tests I wrote) keeps failing inconsistently when I run all tests. Sometimes 1 fails, sometimes 2. It gives different reasons every time.

Last one I got was (as at when I was closing):

I20170628-23:57:26.603(1)?   275 passing (1m)
I20170628-23:57:26.604(1)?   11 pending
I20170628-23:57:26.607(1)?   1 failing
I20170628-23:57:26.610(1)?
I20170628-23:57:26.613(1)?   1) Server/Core shop/createTag should create new tag:
I20170628-23:57:26.623(1)?      Error: Tag shopId is required
I20170628-23:57:26.623(1)?       at getErrorObject (packages/aldeed_collection2-core.js:480:15)
I20170628-23:57:26.625(1)?       at [object Object].doValidate (packages/aldeed_collection2-core.js:462:13)
I20170628-23:57:26.628(1)?       at [object Object].Mongo.Collection.(anonymous function) (packages/aldeed_collection2-core.js:214:25)
I20170628-23:57:26.628(1)?       at [object Object].Mongo.Collection.(anonymous function) [as insert] (packages/dispatch_run-as-user.js:325:19)
I20170628-23:57:26.631(1)?       at Function.invoke (packages/practicalmeteor_sinon.js:2489:59)
I20170628-23:57:26.633(1)?       at [object Object].proxy [as insert] (packages/practicalmeteor_sinon.js:2400:30)
I20170628-23:57:26.634(1)?       at [object Object].shopCreateTag (server/methods/core/shop.js:490:18)
I20170628-23:57:26.637(1)?       at [object Object]._MethodHooks._wrappers.(anonymous function) (server/api/method-hooks.js:128:7)
I20170628-23:57:26.639(1)?       at packages/check.js:129:16

I'll see to resolving this asap, in between moving to another ticket.

[impactmass]

Tests fixed now (thanks to help from @zenweasel). PR ready.

(Updated)

[impactmass]

Update on the Accounts UI rewrite work as at end of day yesterday:
_ I reviewed the current state of new account dashboard PR #2543 with @rhenshaw56
_ Our first task together was to rename components and container to reflect what they really are
_ Then I started modifying data functions to pass groups/users properly to SortabeTable, http://bit.ly/2tM2cj2 and http://bit.ly/2tLJjN7
_ @rhenshaw56 started pulling out all inline CSS from the components (he started with inline earlier)
_ The groups now show with Sortable, but the accounts under each group not showing up... picking up from there today.

Updates:

• Today: 2pm WAT: Accounts are showing under the groups. Working on the Group Switcher dropdown now
• Dropdown showing.... next connecting it to group/addUser
• Update: Invite Admin form added
• More update: Group dropdown switch in place. Minor concern found with existing Accounts publication... Adding separate pub for AdminAccounts

[impactmass]

Status of the UI: screen_recording

[impactmass]

I've accomplished:
i) A bunch of CSS cleanups on the existing PR #2543 to make the table easier to style as the mockup has it
ii) Added sorting to groups to show owner group at the top
iii) Added and finished addGroupMember module (focusing on base functionality and not perfect styling for now)
iii) Current view

Today, I'll be working:
_ on editGroup module of the design
_ on createGroup module of the design

[rymorgan]

@impactmass The Two-factor column doesn't need to be included b/c it's something we don't' have yet. I added it to the mock because it's something we want to add down the line.

[rymorgan]

Adding these files here since this is the issue that's being updated with status.

Screens:
Intial User Screen- https://zpl.io/Z162xqi
Edit Permissions Screen - https://zpl.io/nVX8n
Edit Groups - https://zpl.io/Zh8Rdn
Add Group - https://zpl.io/ZTEMLM
Edit Owner - https://zpl.io/15nVaK

[impactmass]

Detailed update/status (plus beginning of PR review) on the PR here #2543

[impactmass]

After merging in #2543 (which sets up base UI for creating and editing groups, switching user from one group to another, and adding users to groups), I'll be making the updates below as @spencern mentioned them while we walked through the UI:

(i) Let the "remove" button change a user to customer group, instead of no group at all
(ii) When a new group is created, use default customer permissions + "dashboard" as the base permissions.

[impactmass]

Resolved with the work done in #2588 and #2194