Uploaded image for project: 'Sakai'
  1. Sakai
  2. SAK-14766

Deselecting both dropbox.own and dropbox.maintain permissions for a role results in folder with no name



    • Type: Bug
    • Status: Verified
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.4.0, 2.4.1, 2.5.0, 2.5.2, 2.5.3, 2.6.0
    • Fix Version/s: 12.0, 19.0
    • Component/s: Drop box
    • Labels:
    • 12 status:
    • 11 status:
      Please Merge


      At Stanford, we have some custom roles (like Guest, Librarian) that should not have access to any other student's data, but also don't need a Drop Box folder of their own. When we deselect both the dropbox.own and dropbox.maintain permissions for these roles, it doesn't really disable access to the tool. Instead, it creates a folder with no name when such a user clicks on the Drop Box tool. Some instructors really don't want these extraneous drop box folders hanging around, although they want to keep these extra roles.

      Some tools (e.g., Gradebook) display a message that the user doesn't have access to the tool when the user's role has no permissions enabled for the tool. Other tools (e.g., Mailtool) just don't display in the left navigation bar when the user's role has no permissions enabled. Either of these methods would be preferable over the current behavior.

      I am attaching screen shots of what this no name Drop Box folder looks like when a user whose role has both dropbox permissions turned off clicks on Drop Box in the left navigation bar. These are taken from Sakai nightly 2.6.x.

        Gliffy Diagrams


            Issue Links



                • Assignee:
                  buckett Matthew Buckett
                  cdoherty@stanford.edu Christine Doherty
                • Votes:
                  0 Vote for this issue
                  3 Start watching this issue


                  • Created:

                    Git Source Code