Remove asset status + refactor how assets and plans are archived

[mstenta]

This is a followup to #978, as described in https://farmos.discourse.group/t/proposal-remove-status-field-from-assets-and-plans/2319

This is a breaking change to the farmOS data model's asset and plan entity types. Here is a quick overview of what this does:

• Repurposes the archived field on asset and plan entities to indicate whether or not the entity is "archived" (not shown in the UI by default).
• Removes the archived status option from the plan entity status field's default state machine workflow.
• Adds additional planning, done, and abandoned status options to the plan entity status field's default state machine workflow. This accomplishes two goals:
  • It avoids the awkward situation left by removing the archived status, leaving on the active status remaining.
  • It adds 3 new useful status options!
• Removes the status field from asset entities.

See the forum topic linked above for the full context and discussion.

[mstenta]

Notes from dev call:

• Make sure active is the default initial state for plans.

[paul121]

Adds additional planning, done, and abandoned status options to the plan entity status field

Re: the status options for plan entities, just wanted to mention we had added custom states for the Rothamsted Experiment plan (requested, planning, active, completed, cancelled and archived). These new plan states align well. But one I think I have always wondered is the naming of "planning" vs "planned". It seems the "planned" would be more consistent, but not sure what is best. I'm curious if this was considered?

[mstenta]

But one I think I have always wondered is the naming of "planning" vs "planned". It seems the "planned" would be more consistent, but not sure what is best. I'm curious if this was considered?

In my mind, a status of "planning" means that the plan is in the process of being built.

A status of "planned" would imply that the planning process is done, so it would be different from "planning". I could see that being useful, perhaps, in some situations, but probably isn't necessary in the default set of statuses we provide out of the box. If a custom planning module needs that level of granularity for its workflow then it can provide that.

[paul121]

I did not test locally, but this all LGTM. Great changes, hope this simplifies things going forward

[paul121]

this should use the new $entity->getOriginal() method we will start using after #980 is merged

[mstenta]

Yes! I'll merge this and then rebase #980 on top and make sure this is updated with it.

[mstenta]

Make sure active is the default initial state for plans.

I tested this, and the default status is planning. But I think that's OK. It makes sense to start it off in that status, to encourage users to go through the logical steps (planning -> active -> done).