Documents in a folder should be shared with its group by default #1548
Conversation
ClaireLozano
force-pushed
the
document-in-folder-members
branch
from
a01d54d to
ee524a6
Compare
node_modules/oae-content/lib/api.js
Outdated
| var createFn = _.partial(ContentDAO.Content.createContent, contentId, revisionId, ctx.user().id, resourceSubType, displayName, description, visibility, otherValues, revisionData); | ||
| ResourceActions.create(ctx, roles, createFn, function(err, content, revision, memberChangeInfo) { | ||
| // If the content is on a folder, add those members to the content created | ||
| _getFolderMembers(ctx, folders, roles, resourceSubType, function(err, roles) { |
There was a problem hiding this comment.
aha! here's the problem. These are the roles that are currently valid, but this is not what we want, is it? we want the permissions that have been defined by the user in the "shared with" form. Those are the ones we want.
A good strategy would be to pick the current ones and then filter them using the form. That way we would have the folder roles, e.g.
{ 'u:up:SkmX6OL9M': 'manager', 'u:uc:HyDW6O8qf': 'editor' }
and then compare it to what comes through the form. For instance, if one user has been removed from the input field inside the modal box, we take it out and it becomes
{ 'u:up:SkmX6OL9M': 'manager' }
See below 👇
There was a problem hiding this comment.
The POST that is sent when one creates the document goes like this (in my local scenario):
resourceSubType:collabdoc
displayName:My private fifth document
description:
visibility:private
managers:u:up:SkmX6OL9M
managers:u:up:SkmX6OL9M
folders:f:up:rkqGJYUqG
So you see, that's the baseline we should be using: { 'u:up:SkmX6OL9M': 'manager' }. The current folder permissions don't matter.
On another test, where I didn't remove any users from the "Shared with" field, this is what I got:
resourceSubType:collabdoc
displayName:My public document
description:
visibility:private
managers:u:up:SkmX6OL9M
managers:u:uc:HyDW6O8qf 👈
managers:u:up:SkmX6OL9M
folders:f:up:rkqGJYUqG
...which confirms my approach: this is what we need roles to contain. 👍
There was a problem hiding this comment.
I finally removed all my code (no code, no mistake haha) because I get all members on 3akai-ux and there is no need to add code in Hilary but there is something that still bothers me... On a collabdoc, if a user is added on the "setpermissions" modal, they will be added as manager.
-> So if there is 30 viewers on a folder, when a collabdoc is created inside the folder, this collabdoc will have 30 managers (+ the creator of the resource).
For me, a viewer of a folder should be editor(or viewer) but not manager ... I don't know, that's just my point of view.
(Just for information, viewers and managers of folder will become viewers of a link created inside the folder.)
There was a problem hiding this comment.
For me, a viewer of a folder should be editor(or viewer) but not manager ... I don't know, that's just my point of view.
I agree. We need to make a folder viewer into a collabdoc editor.
ClaireLozano
force-pushed
the
document-in-folder-members
branch
from
bfa596e to
5287a20
Compare
|
Review status: all files reviewed at latest revision, 1 unresolved discussion, some commit checks failed. Comments from Reviewable |
|
Review status: all files reviewed at latest revision, 1 unresolved discussion, some commit checks failed. node_modules/oae-content/lib/api.js, line 543 at r1 (raw file): Previously, brecke (Miguel Laginha) wrote…
This is the only comment from this review.. but I'm not sure this is done or whether this was just an idea, you tell me Comments from Reviewable |
|
Reviewed 1 of 1 files at r2. Comments from Reviewable |
Issue : #1407
This change is