Documents in a folder should be shared with its group by default

[brecke]

From uservoice:

When you create a document inside of a folder, the document correctly receives the visibility of the folder as the default visibility. But, the documents in the folder are not shared with the group by default. It should have the same sharing settings as that of the folder.

Testing

Note: The Inherit folder invitations? represents the fact that I have decided not to inherit invitations (made on the folder) to the content created / uploaded on that folder. The permissions are inherited (editor, viewer, manager) but the invitations are not.

• Collabdoc
  • Users only
  • Users and invitations
  • Inherit folder invitations?
• Collabsheet
  • Users only
  • Users and invitations
  • Inherit folder invitations?
• Single Link
  • Users only
  • Users and invitations
  • Inherit folder invitations?
• Multiple Links
  • Users only
  • Users and invitations
  • Inherit folder invitations?
• Single Upload
  • Users only
  • Users and invitations
  • Inherit folder invitations?
• Multiple uploads
  • Users only
  • Users and invitations
  • Inherit folder invitations?

[ClaireLozano]

Hi !

I made a pull request here : #1548

It works but I broke the unit tests of the module "oae-content" ... Can you review the changes before I repair the unit test.

[brecke]

I'm on this. Which tests are failing exactly? And have you ran the whole suite?

[ClaireLozano]

Hmm ... almost all (in oae-content) :

17 passing (33s)
170 failing

I didn't ran the other tests

[brecke]

Uhh.. that's goint to take some work then. But before that, I think we need to redesign the solution to this.

The current behaviour is content being shared with the group as read-only, correct? All the group members can see the document, but just as a "viewer", not as an editor. The problem lies on the fact that they are never made editors even if they have "manage" access on the folder. So, with that in mind, here's what we need to to:

1. We need a way to make it clear to the user that he can inherit the writing permissions when creating a document, and make it default behaviour. I'd suggest something like this:

Then when the user clicks "Update", the following modal box should display a slightly different message such as

This document will be added to My library and Folder shared with some people. It will be private and only visible to the people and groups you share it with but will respect the parent folder permissions it's being created in.

2. If we create a document using this new behaviour (checkbox checked), we need to make sure we "merge" the default "private" permissions with the ones we get from the folder (especially the "manage" ones).

3. Finally, if we go to "Manage access" on the newly created document, we need to make sure the merged permissions are correctly shown there.

Does this make sense to you @ClaireLozano ? Tell me your thoughts.

[ClaireLozano]

Okay, I have some questions :

• We agree that "visibility" and "share with" are two different things right ?
  So "inherit permission" will just apply the same folder visibility to the new document and have no effects on members ?

• Do we propose to the user to inherit or not the members of the document ? Or we do it by default ?

• what I've done is that all viewers of the folder became viewers of the new document and same for managers but that means that it will never have editors so ... we can say that all viewers of the folder became editors (?)

The current behaviour is content being shared with the group as read-only, correct? All the group members can see the document, but just as a "viewer", not as an editor.

That's weird because yes they can view the document but the document isn't shared with them, that's what we call indirect roles (?)

[ClaireLozano]

The feature is ready to be reviewed.

So ...

• I added the inherit visibility (front)
• by default all the members of the folder will be members of the content
• and in the case of collabdoc, all the viewers of the folder (folder have only viewers or managers) will be editors of the content.

It seems correct to you ?

[brecke]

Hello,

Sorry I took so long to reply.

I think I may have not expressed myself very well but in the end I think you got it :) The new setting isn't about visibility, it's about permissions, so I think that maybe we could do something slightly different on the frontend, to make it simple. That would be to include on the Shared with section all the users the parent folder is currently being shared with, like so:

☝️ this assumes User #1 and User #2 are members of the parent folder

So the "default" would be as you said, but the user would still have the ability to create a "private" document like before if he/she removes those users before creating it.

What do you think?

Other than this visual change, I agree with your statements above 👍

[ClaireLozano]

Oooh ok I get it ! And yes I think it's the best thing to do :)

[ClaireLozano]

Done ;) The feature is ready to be reviewed !

[brecke]

Will do, on Monday!

[brecke]

Hi Claire,

I've just tested the feature and the "Inherit folder visibility" is still there, apparently. I don't think it fits anymore, given the solution we designed for this issue.

Apart from that, I don't think this is working as expected. Let me give you an example:

1. UserA creates folderA
2. UserA adds UserB as manager of that folder
3. UserA creates a document inside that folder and UserB sees it, which is correct
4. UserA creates a document inside that folder but removes UserB from the "Shared with..." field. Creates is and UserB still sees it (can edit).

☝️ this is not expected beaviour. If we're displaying the users the parent folder is currently shared with, then we must adapt the permissions on the document we're creating accordingly. Right now, the user is getting "can edit" by default no matter what the user picks in the "shared with" field.

Do you confirm this behaviour?

[brecke]

I'm cancelling this issue. I'll provide a short explanation below:

This issue makes sense. Currently, if user A creates a folder, shares it with user B (as manager) and then creates a document inside it, user B will hold the viewer role on that document. In theory, according to general user hierarchy understanding and expectations, if user B is a manager of the folder, he should also have manager role on all folder contents for as long as the folder exists. So this would be a good fix. This line of thought could also be applied to invitations.

This approach is implemented on PR #2096 (the first approach from Claire one was frontend only: oaeproject/3akai-ux#4235) but I never got to fix tests, because I have since come to the conclusion this issue is superseded, since folders are going to be converted into labels (tags) on the next major version (and redesign) of OAE.

If you check the wiki page for details on files vs folders.