Uploaded image for project: 'Grouper'
  1. Grouper
  2. GRP-2441

tree display performance with permissions turned on

    XMLWordPrintable

Details

    • New Feature
    • Resolution: Unresolved
    • Minor
    • None
    • 2.4.0, 2.5.54
    • UI
    • None

    Description

      I prefer explicit permission models instead of implied.

       

      Example: If there was a "folder view permission" then groups could be given access to see a folder. ( or "the magic All subjects thing" could be used too.)

       

      To achieve the current implied  folder visibility design: ( or turn it off  at the root or at some level down the tree, if you don't ):

      A rule (on the root folder) on folder create:
             create a "view folder group" for the new child folder.
             Add the child folder "view group" to have view to the parent folder ( by adding it to the parent folders "view folder group").

       

      That way as folders are created and people are allowed to see a N level deep folder, they will automatically be able to see all the N-1 level deep folders above it back to the root.

       

      Another rule could:
      if a group/user can see an object in the a folder auto add them to the "view folder group" 

       

       

      In this model a user might have access to something in a N level deep folder that they can not see the whole path too in the UI folder tree. ( Which is fine with me. ) They should be able to search and find, bookmark, find via services those things too.

      I would expect the tree to "add parent folder(s) back up to the root" when a user "jumps" to an object from a search. ( Picture long chain of "closed" folders back to the root with only the children object(s) of the last folder being added to the tree. )

      If a user selects a "higher level folder" that they don't have explicit access to, then they see nothing and nothing changes in the tree. ( no error, no message, must a "folder with a child folder".

      All I am really talking about is making the permissions that drive the tree structure in the UI local to each folder so that a "search of a single folder's child folders/objects" is all that is ever needed for the "open" tree folder. 

      When a folder is selected in the tree then becomes an "open folder" and then it's child objects are added to the tree and closed child folders are added to the tree as well.

       

      It's a fairly big ask, but it makes the UI more "permission driven" and avoids "loading the whole tree" (at any time) to do it. 

       

      And maybe other indexing approach could be done to "fix performance" too. However, this approach adds a feature that would allow users to have a simplified folder UI structure as well.  (And that could be achieved other ways too. I like using ACL's to provide the most flexibility to the deployer. )

      Attachments

        Activity

          People

            chris.hyzer@at.internet2.edu Chris Hyzer (upenn.edu)
            carey.black@at.internet2.edu Carey Black (osu.edu)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated: