Project category

[bfoley12]

Summary

Introduced 4 ways to group projects and implemented improved business logic around permissions and projects.

Major changes:

• Initiative: the "canonical" grouping of projects. Only owners/collaborators of both the Initiative and Project can include the Project in the Initiative. Ie. A Lab has ALab-Project1 and ALab-Project2. Here, ALab would be the Initiative that includes [Project1, Project2].
  • Limits:
    1. Users can only have 3 unapproved Initiatives at at time
    2. An Initiative can only have 2 unapproved projects at a time
  • Creates a new collection in MongoDB "initiatives"
• ProjectGroup: a user-controlled grouping of projects. Allows assignment of any projects (within a user's scope) to a group for easy viewing/access. This is more general than the Initiative, and only functions for the user to keep similar, interesting projects easy to access
  • This fell out naturally during development, but there could be limited use in the front end. Can separate out into a different branch
  • Creates a new collection in MongoDB "project_groups"
• MP Category: An optional field on Projects to denote the broad category MP places a project into. Ie. "batteries", "catalysis"
  • Can only be modified by admins
• Tags: Tags are a field on projects that Users can add to if they own/collaborate on it. This can be used to more easily find similar projects. Ie. "find all projects tagged with '2D'"
  • This is not a controlled vocabulary
• User Roles: Initiatives and ProjectGroups rely on prefixed roles from Kong since we should not require uniqueness across all Initiatives, ProjectGroups, and Projects.
  • Projects: "" (unchanged)
  • Initiative: "initiative:"
  • ProjectGroups: "project-group:"

Reviewer Guide:

Note: ~1,500 LOC in src, ~1,800 LOC in tests

• Backbone Logic
  • authz.py
    • Added info to user roles - a prefix must be used to define user access to initiatives and ProjectGroups (Lines 36-45)
    • Added convenience properties and methods to serve roles and determine access (Lines 77-112, 120-129)
  • _shared
    • types.py
      • Added str parsing types
        • SearchStr: relies on NFKC normalization and casefolding
        • DisplayStr: relies on NFC normalization
        • NFKCStr: NFKC normalization without casefold to preserve case (project + initiative names)
        • Follow this link for more information than you'd ever need
    • filters.py
      • Added custom operator "__contains" - takes a comma-separated string and returns True when the list representation contains a value
    • models.py
      • Added methods for declaring fields that uniquely identify documents
    • repository.py
      • Added methods to make the generic base more usable
• Projects
  • Implemented new concepts: Initiative, tags, mp_category
  • ProjectIn now respects server-managed fields (ie. stats)
  • Improved enforcement of business rules in ProjectsRepository (role requirements for operations, only admins can approve) (Lines 90-110, 114-124, 163-174)
  • Added ProjectService to manage interactions between Projects and Initiatives
• Initiatives
  • look at domains/initiatives for full domain breakdown
  • Initiatives follow similar logic to Projects
    • Owners can have a limited number of unapproved initiatives (default 3)
    • Each initiative can have a limited number of unapproved projects (default 2)
  • Models are minimal for now, but can add metadata later
  • repository.py / router.py - basic CRUD
• ProjectGroups
  • look at domains/project_groups for full domain breakdown
  • A ProjectGroup tracks its Project members
  • repository.py / router.py - basic CRUD
  • service.py - manages operations on Projects in a ProjectGroup (existence and authz checks)

TODO

Outside of this branch, Kong needs to implement the role-scoping