Hierarchical Resource Collections

User organized hierarchical collections

Allow users to organize their resources in hierarchical tags. We're currently conceiving of these hierarchical tags as tag paths, e.g., /tags/foo/bar/baz/quux contains all resources in the quux tag.

The full set of operations that are allowed is still hazy, but a first cut of requirements:

1. Each tDAR user is assigned a tag where all resources they've submitted that don't have an associated project live in which may be their username (email address) or a maybe a generated hash of their username, or a namespace they create themselves?
2. Creating a project creates a new tag namespace. All resources belonging to a project fall under that tag namespace. What do we use for the namespace, the project ID? It needs to be unique.
3. Users can create new tag namespaces as well, and link any resource they have write access to into that tag namespace. Do we allow multiple tag hierarchies for the same resource?

Use cases

1. given a TagPath, find all resources associated with that TagPath
2. efficiently find all parents of the given TagPath (will also be needed for Permissions described below).

Current implementation plan

Create a TagPath entity (name tbd) with

• Name
• Description
• Parent tag
• URI fragment (e.g., /path/to/tagname) - how to ensure unique namespacing and generated tag paths for implicitly created collections, e.g., Projects.
• Type enum
• @ManyToMany to associated resources + Person owner (use a through table / explicit many-to-many entity w/ additional fields)

Permissions and authorization

Get rid of ReadUser, FullUser and set up a proper permissions table. Investigate Shiro and Spring Security and whether or not we want to use their model of authorization for access to a resource.

Use cases

Given some user X and some resource Y (or a collection Z represented by a tag path), how do we efficiently ask the questions:

1. should X be able to access/modify Y
2. should X be able to view the collection Z

Current implementation plan

Maintain a Permissions table that maintains references to

1. TagPath or Resource being explicitly granted permissions (via TagPathPermissions, ResourcePermissions or just a generic Long id and have an additional type field)
2. the permission being granted (read/write)
3. the entity being given permission (a Group or an individual Person?)
4. Person creating the Permission and other audit information as necessary

So we'll either need a Group entity or use Crowd groups...