Extend Project to have Attributes

[dmr-x]

Description

Similar to Allocation with AllocationAttribute et al., add attributes to Project. Ideally, reuse code as much as possible from Allocation et al.

For Project attributes, researchers and staff should be able to work with them. TBD: whether "researchers" is PI-only, managers-only, or all project users.

Task list

• plan
  • [x] preliminary task list
  • [x] map out desired models/relationships as applied to Project
  • [x] determine code reuse potential
  • [x] models
  • [x] forms
  • [x] views
  • [x] templates
  • [x] ~integration~ (this is sectioned inline below for more detail)
• clarify
  • [ ] "researchers": PI-only, managers-only, or all project users?
  • [ ] default projectattributetypes?
  • [ ] come up with a few examples, to discuss defaults
• implementation
  • [ ] new feature
  • [ ] models
    • [x] model classes/fields
    • [x] value conversions
    • [x] default datatypes
    • [x] allowing boolean datatype customization
    • [x] meaningful string representations
    • [ ] permissions TBD: probably a "nice to have"/phase 2
    • [ ] customized boolean datatypes: defaults
    • [ ] app parity ('Yes/No', 'Active/Inactive', 'Public/Private')
      • [ ] as a command + integrated in setup
      • [ ] as a migration
    • [ ] default projectattributetypes
    • NOTE this is pending clarification
    • [x] ~default values~
    • ~NOTE: null or uninitialized / etc. to be set for pre-existing projects (TBD)~
    • decided this can be handled in-app, more flexibly
    • [ ] model attribute handling
    • [ ] is_unique
    • [ ] is_required - probably as QuerySet helper function, to get ~null required (not yet defined) attributes in a result too
  • [x] admin views
    • [x] field listing, sorting, editing, etc. settings
    • [x] handling value conversions/validation
    • [x] useful string representations (had to do a workaround)
  • [ ] forms
    • [x] research ModelForm feasibility w/ model properties
    • [ ] implement form
    • [x] ~akin to existing code~ (was no good/applicable reference)
    • [x] property field
    • ~other stuff (see views below, to not double-list)~
  • [ ] app views
    • [ ] project attribute
    • [ ] add
      • [x] saving, permissions
      • [x] saving, basic
      • [ ] form-mediated stuff
      • [ ] saving, value/type validation
      • [ ] saving, project cannot be modified
      • [ ] remove "is_private" options from <OPTION> list
    • [ ] edit
    • [ ] delete (single, not multiple)
  • [ ] templates
    • [ ] project attribute
    • [x] add
    • [ ] edit
    • [ ] delete (single, not multiple)
    • [x] javascript usage ~TBD - probably a "nice to have" none currently foreseen~
  • [x] urls (mostly; view implementation not complete)
  • [ ] CLI commands (e.g. import) TBD: probably a "nice to have"/phase 2
  • [ ] integration
  • [x] plan
    • [x] researcher-side navigation pathway - probably some directly on project detail page, some w/in their own page(s)
    • [x] ~staff-side navigation pathway (navbar?) - can probably be cruder than researcher-side~
    • for adding attribute types, admin view is the only supported way for other models; following suite
    • for editing, will simply use the same views/navigation pathway (however, see "nice to have" below)
  • [ ] app view & templates
    • [ ] project create (for required attributes; others can be set later)
    • [x] project detail
    • [ ] ~alert when project is missing a required attribute
    • [ ] project review TBD: probably a "nice to have"/phase 2
    • [ ] all-projects attribute listing (new view/template) TBD: probably a "nice to have"/phase 2
    • [ ] all-projects attribute filter TBD: probably a "nice to have"/phase 2
• unit/automated testing
  • [ ] TBD
  • [ ] view
  • [ ] construct as_view(); save
  • [ ] form
  • [ ] construct; save good value, attempt save bad value
• manual testing
  • [x] models
  • [x] admin views
  • [ ] app views
  • [x] project detail (mostly; implementation not complete)
  • [ ] others yet to be enumerated...
  • [ ] TBD
• general branch management
  • [ ] depends on #8 (core/utils, 2073e131828639956271e8be1687cbd3bdf132b0, currently cherry-picked)
  • [ ] merge/conflict management (#12 in particular has the potential to create conflicts)
• upstream PR prep
  • [ ] address any comments from code review
  • [ ] combine [FIXUP] commits into offending commits
  • [ ] rebase onto upstream master
• final refinements
  • [ ] updates based on upstream feedback

[dmr-x]

@artlogic: Planning out the implementation gave rise to a needed clarification:

TBD: whether "researchers" is PI-only, managers-only, or all project users.

This is not a blocker for implementation, and generally should be something that can be changed fairly easily.

Where it might get complicated is if, like Allocations themselves, various users are allowed to manage the attribute. If it's a flat/simple permissions structure, then shouldn't be very complicated to change later.

[dmr-x]

dmr-x closed this Mar 4, 2020

I think GitHub did this automatically when I force-pushed the new master. Re-opening.

[dmr-x]

Updated task list.

Notably added another clarification task:

• default projectattributetypes?
  • come up with a few examples, to discuss defaults

Per our discussion, the subtask is on me.

@artlogic: I've fleshed out some of the task list. You may want to review it for things to cut out. Atm, the TBDs/"nice to have" are listed for informative purposes only, as I don't plan to do them in the near future (due to our timeline).

Additionally, I expect the pushed code to change very little going forward, so feel free to review it.

[dmr-x]

Pushed some [WIP] code (everything seen works - just need to build more to consider this chunk complete).

Updated task list.

[dmr-x]

Pushed some more [WIP] code (again, everything seen works - just more needed to consider complete).

Updated task list.