Meta issue: action and project models

[C-Otto]

There are several issues asking to change the models of actions and projects, for example duplicating features already available for actions also for projects, or fine-tuning the possible states. This issue is a collection of such issues.
#1316 add tags for projects
#1425 dependencies between projects and actions

#1423 dependencies in hidden projects #1981
#1082 consistent hidden states #1981
#790 dropped state for actions and projects
#686 due date for projects
#790 dropped state
#942 due date for projects
#1413 transitive deadlines
#1424 pending vs. 'show in x days'

[C-Otto]

The following is a sketch of how all the ideas could be integrated based on the current implementation. There are many questions, and would be very risky to implement all changes in one go. Nevertheless, I feel it would be great to have a complete list of everything related to these issues.

Additions to the current implementation are marked in bold.

Each action may have one of the following states:

• active
• completed (only if also completed at is set)
• dropped (only if also dropped at is set) add a "dropped"-state for actions #790

Additionally, (only?) active actions may have any combination of the following states #1423 #1424 :

• deferred (derived from show from)
• pending (derived from predecessors)
• hidden (derived from project/context) get consistent hidden states #1082 (fixed with Remove project hidden state #1981)
• starred (derived from tags, only used for fancy UI stuff)

There also is the idea to have a 'someday' state #1581. However, I think this can be solved by using a (hidden) project or context for such actions.

Each action may have the following properties:

• context
• project
• description (similar to project name?)
• notes (similar to project description?)
• created at
• due
  • can be set
  • can be derived from project's due date
  • can be derived from successors' due dates
  • compute minimum of all these values? Transitive deadline for dependency actions #1413
• completed at
• user
• show from
• state
• recurring todo
• updated at
• rendered notes
• many predecessors (see below)
• many successors (derived from predecessors)
• tags
• dropped at add a "dropped"-state for actions #790

Each project may have one of the following states:

• active
• completed
• dropped add a "dropped"-state for actions #790
• hidden

Projects may also be deferred or pending, see discussion below.

Each project may have the following properties:

• name (similar to action description?)
• position
• user
• description (similar to action note?)
• state
• created at
• updated at
• default context
• completed at
• default tags
• last reviewed
• many tags (shared with actions' tags?) Add tags for projects #1316 "relative" due date entry? #317
• due date projects need default due date, default 'show from' #942 Add due dates for projects #686
  • can be set
  • can be derived from successors' due dates
  • compute minimum of all these values? Transitive deadline for dependency actions #1413
• show from
  • also see the discussion in projects need default due date, default 'show from' #942, maybe it suffices to use show from for the project's actions

Dependencies #1425 #373 #1423:

• each action can depend on multiple other actions
• each action can depend on multiple projects
• each project can depend on multiple actions
  • also see the discussion in projects need default due date, default 'show from' #942, maybe it suffices to have actions depend on actions/projects
• each project can depend on multiple other projects
  • also see the discussion in projects need default due date, default 'show from' #942, maybe it suffices to have actions depend on actions/projects

Currently there are no dependencies involving projects.

Actions and projects share the following properties and could benefit from a common superclass:

• description/name
• user
• context/default context
• notes/description?
• created at
• due
• completed at
• show from
• state
• updated at
• many predecessors (see below)
• many successors (derived from predecessors)
• many tags
• dropped at

Some random notes:

• explicit states are useful because of guards in state machine
• how much impact do derived states/properties have on runtime? get consistent hidden states #1082
  • add boolean "is pending" or "is hidden" to optimize? do this later?
  • first remove hidden state Remove project hidden state #1981