Project directory not shared to project

[fredrik]

The project directory is not automatically shared with write permission to the active project. This means that even if a project is share to another user with write permission, the other user cannot generate a report that writes to the project directory. Refs #516.

[olle]

Ticket reassigned to olle.

[olle]

Ticket accepted.

[olle]

Traceability note: The ticket referred to in the ticket description is Ticket #516 (project files showed as shared).

[olle]

Tests performed on current version of Proteios SE:

1. As user A (User, Power user), a project containing Hits data was shared with new user B (User, Power user) with permissions Use, Read and Write. Logged out as A and logged in as B, where the project shared by A now was shown in the project listing. The project was selected to be active, and the Hits table was displayed. Function "Export to File" was selected with option "Shown items only", after which a message was shown stating that the table contents had been exported to file "export_20090325_130049.tsv" in the project directory. Navigated to the latter, where the export file in question was shown in the list. The export file was selected and downloaded to the local file system for inspection. It contained the expected data. In this case user B was able to create a file in the shared project's directory.
2. In order to perform a test under even more clean conditions, a new user C (User) was created. As user B a new project was created, and a file was uploaded to the project directory (an image file, that can be inspected directly in Proteios SE). The new project was shared with user C, with permissions Use, Read and Write. Logged out as B and logged in as C, where the project shared by B now was shown in the project listing. The project was made active, and the project directory file listing showed the previously uploaded image file, which could be inspected directly. As user C an mzData file was uploaded to the same directory without problem.
3. Using the same test setup as in case 2, as user B (the one that had shared the project) a sub-directory to the project directory was created, and a file was uploaded to the sub-directory. As user C this file could be inspected in the sub-directory to the project directory of the project shared by B. C could also upload a new file to this sub-directory.

In summary, the tests did not encounter anything that could not be performed in the project directory of a project, that had been shared by another user.

[olle]

Test update - Further information regarding the circumstances under which the reported problem occurred, lead to a problem that could be reproduced on the test system:

1. As user A (User, Power user), a project "Tissue" containing Hits data was shared with new user B (User, Power user) with permissions Use, Read and Write. Logged out as A and logged in as B, where the project shared by A now was shown in the project listing. The project was selected to be active, and the Hits table was displayed. Function "Combined Hits Report" was selected, after which a job was created. The latter ended with an error due to "Permission denied: Not allowed to write Directory[id=8; name=Tissue]".

[olle]

Comments on the problem of creating a combined hits report in a project not owned by oneself, but which one has been made a member of by the project's owner:

• Plug-in CombinedHitsReport performs an explicit check that one has WRITE-permission for the output directory, which is where the PermissionDeniedException is thrown. It is very common for plugins to perform this type of check.
• If the owner of the project in question makes the project active, navigates via the GUI to the home directory, checks the check box of the project directory, and clicks button "Use in project", it was found that another user that had been made member of the project could successfully create a combined hits report, where the output file was placed in the project directory. However, the initial operation is unorthodox, since the "Use in project" option is intended for using directories and files created in other projects than the one in question, as directories and files created in a project should already be associated with the latter. Also, the created output file was owned by the user who created it, although it was placed in the project directory of a project owned by another user. This prevented the original user from sharing the project directory with new projects, as a PermissionDeniedException was thrown when attempting to modify the permissions of the combined hits report output file.

[olle]

Test of permissions for the project directory of a shared project owned by another user.

Test setup:

• Class/file action/project/ViewActiveProject.java in client/servlet/ was updated in public method void runMe() to add an extra row in the table showing project permissions for the different users. The extra row showed permissions for the logged-in user for the project directory of the active project. To obtain information on a specific project, the logged-in user must therefore be a member of the project, since it otherwise could not be made the active project.

Testing was performed by logging in as user A and sharing a project owned by A to another user B with a specific set of permissions. User A then logged out, and user B logged in. The project shared by A was made the active project by B, and the member permissions table for the project was inspected. The test was repeated using different sets of permissions when A made B a member of the project.

Test results:

• Results indicate that a user gets default permissions for a the project directory of a shared project owned by another user, based purely on the Role of the user the project was shared to, where Role USER gives READ, USE, and CREATE permissions. The latter permissions were the only ones found for the project directory of a shared project owned by another user, whether the user had been made a member of the project with only READ permission, the most restrictive set of permissions, or full permissions of READ, USE, CREATE, WRITE, and DELETE.

The owner of the project always had full permissions of READ, USE, CREATE, WRITE, and DELETE for the project directory.

[olle]

Test update:

• Further testing showed that the results reported in comment added 2009-04-23 10:03:37 by olle seem to be correct for newly created projects, but for some older projects it was found that the a WRITE permission set when user B was made a member of a project owned by another user A, did indeed also result in a WRITE permission for the project directory for user B to whom the project had been shared. For the latter project, if the project owner A changed permissions when sharing the project to user B by excluding the WRITE permission, user B also lost the WRITE permission to the project directory of the shared project. This showed that B did not always have WRITE permission to the project directory of the shared project, but this depended on the permission set for the latter.

Why the permissions granted to a user for the project directory of shared project owned by another user, for some projects seem to be independent on the permissions set when granted access to the project, and for other projects seem to be dependent on the permissions set, is currently not known.

[olle]

Analysis of difference in test results between tests described 2009-04-01 11:25:31 and 2009-04-22 12:02:09:

1. As noted in comment added 2009-04-22 13:09:19, plug-in CombinedHitsReport performs an explicit check that one has WRITE-permission for the output directory. This check is performed by many plug-ins.
2. When uploading a file to a directory, or using action class ExportToFile to create a new file item in the project directory of the active project, a check is performed that one has USE-permission for the output directory, when the latter is set as the directory in which the new file item is located. (The test is performed in public method void setDirectory(Directory directory) in class/file core/File.java in api/core/.)

If permissions for the project directory of a shared project, not owned be oneself, are READ, USE, and CREATE, creating a file in the second case will be allowed, but denied in the first. Permissions READ, USE, and CREATE are the default directory permissions for a user with role "User".

[olle]

Discussion of alternative solution:

• Permission USE for a directory allows a user to save a new item in it, while permission WRITE is only needed to change some directory property, like name or description. The latter is normally restricted to the owner of the directory, and the administrator. It has therefore been suggested that instead of changing what permissions are set for the project directory when a project is shared, plug-ins should be changed to check for permission USE instead of WRITE, when they need to place a new item in a directory.

[olle]

It was decided to use the solution suggested in comment added 2009-04-29 14:29:24:

• Plug-ins should be changed to check for permission USE instead of WRITE, when they need to place a new item in a directory.

This should solve most problems concerning creation of new files and directories in a directory tree of a shared project, not owned be oneself, without introducing low-level changes to the permission system.

[olle]

(In [3250]) Refs #529. Plug-ins modified to check for permission USE instead of WRITE, when they need to place a new item in a directory. The update is intended to solve most problems concerning creation of new files and directories in a directory tree of a shared project, not owned be oneself, without introducing low-level changes to the permission system.

Modified classes/files for plug-ins in plugin/:

1. plugins/CombinedHitsReport.java
2. plugins/DecyderXMLtoDIGEAnalyzer.java
3. plugins/DtaToMzMLPlugin.java
4. plugins/ExclusionListFromHits.java
5. plugins/MsInspectDetailsImporter.java
6. plugins/MsInspectPairFinder.java
7. plugins/MsInspectSearchResultsToCSVFile.java
8. plugins/mzdata/MzDataExportPlugin.java
9. plugins/MzDataContactDataAdderPlugin.java
10. plugins/MzDataSampleDataAdderPlugin.java
11. plugins/MzMLContactDataAdderPlugin.java
12. plugins/MzMLSampleDataAdderPlugin.java
13. plugins/PklExportPlugin.java
14. plugins/PklToMzDataPlugin.java
15. plugins/PlgsToMzDataPlugin.java
16. plugins/PlgsToMzMLPlugin.java
17. plugins/PrideExportPlugin.java
18. plugins/ProteiosProteinAssembly.java
19. plugins/SearchResultsPepCSVMatch.java

[olle]

Test of solution using procedure that originally lead to a problem on the current system:

1. As user A (User, Power user), a project "Tissue" containing Hits data was shared with new user B (User, Power user) with permissions Use and Read (not Write). Logged out as A and logged in as B, where the project shared by A now was shown in the project listing. The project was selected to be active, and the Hits table was displayed. Function "Combined Hits Report" was selected, after which a job was created. The latter finished successfully having created a file with the desired output in the project directory of project "Tissue". The file could be accessed both by user B and user A.

[olle]

Ticket closed, since the implemented solution should solve the most urgent problems concerning work in a shared project, not owned by oneself. In order not for the problem to re-appear, new plug-ins should check for permission USE instead of WRITE, when they need to place a new item in a directory.