Define reuse policy

[aclark4life]

We intend uu.task to be reusable by other add-on developers. What features do we want to include for add-on developers? Relevant comment from @seanupton:

We cannot guarantee that all other types in other add-ons extending behavior are containerish
(those that are not should not support subtasks). It may also be the case that some other types 
that are like tasks using the behavior won't want sub-task support (e.g. make this opt-in for the 
behaviors story).

[seanupton]

@aclark4life here's my first take, may not be complete...

How other add-ons can extend uu.task

Use behaviors

• A task behavior should allow a Dexterity-based content type in another add-on to add the behavior to its FTI, and this should provide to that type:
  • "Task" fieldset and fields on add and edit forms
  • Assumed some fields in this fieldset provided by collective.task and others by uu.task interfaces/schema.
  • "Task assignment" view and associated object tab/action.
  • A marker interface indicating that content is a task.
  • Ability for task notification system to find content using portal_catalog 'object_provides' index.
  • Discoverable by uu.task notification system, treated as equal with OOTB task type.
  • Sub-task abilities should be optional.
• A "task container" behavior should allow any Dexterity-based containerish/folderish type to add behavior to its FTI, and should provide to that type:
  • "Task" fieldset and fields on add and edit forms
  • Provides fields for default configuration to be shared/acquired across contained tasks, unless contained task has specified override.
  • "Task assignment" view and associated object tab/action.
  • More limited than form/view for a task, because this is only about setting defaults.
  • Goal: make it possible for users to avoid repeating themselves when setting up a series of tasks.
  • A marker interface indicating that content is a task container.
  • Ability for task notification system to find content using portal_catalog 'object_provides' index.
  • When notification system is recursively looking for rules/configuration, by walking up the hierarchy of parents, marker interface helps ascertain stopping point.

Assigning principals (hooks/vocabulary)

• Should be possible for another add-on to create an alternative name/title pair of vocabulary terms for groups.
  • Should be sensitive to location/context (e.g. if a task is contained within a collective.teamwork workspace/team, within a collective.workspace project).
  • collective.workspace has workgroups for each workspace, we want to be able to pick from their rosters.

[seanupton]

@aclark4life not yet a requirement, but when we get to making assigning principals pluggable:

• I will need to detail the requirement more than already documented. My sense is somehow that add-ons outside uu.task would be able to override the default group enumeration (vocabulary) used by collective.task, such that a drop-down vocabulary might look like:

Workgroup members:
- "UPIQ Using Antibiotics Project Wisely" (project) members
-- "Alpha Clinic" (team) members
--- "Alpha Clinic North" (workspace) members
Workspace managers:
- "UPIQ Using Antibiotics Project Wisely" (project) managers
-- "Alpha Clinic" (team) managers
--- "Alpha Clinic North" (workspace) managers

Note: I do not expect uu.task to provide this sort of vocabulary, but rather just have hooks to allow for an override (of default collective.task/uu.task vocab) by other packages. These titles are simply something that front for PAS groups that should work with the way collective.task already does user/group selection with master-selection AFAICT.

• We should likely add https://github.com/upiq/collective.teamwork.git as a mr.developer source to the buildout used for development.