@paul121 and I had a chat about this a few weeks ago and I want to capture it here for public consideration.
Proposal: Remove the status field from assets and plans and replace it with a boolean archived field.
This would change the data model so that assets and plans are either “archived” or “not archived”, but do not have an explicit “status”.
The benefit of doing this is it separates the concept of “archived”, which in practice is simply a mechanism for hiding/filtering out assets/plans in the UI/API.
This would allow other modules to add their own “Status” field(s) to assets/plans, which can be more targeted to use-case-specific workflows.
For example, a custom plan type may want to provide its own set of statuses, instead of the default “Active” status.
Worth noting, this would actually be a bit more like the original farmOS v1 data model, which changed in v2. In farmOS 1.x, assets had a property called archived which was either 0, which indicated that the asset was active, or a timestamp that recorded when the asset was archived. In farmOS 2.x, these were split into two separate fields:
status - The status of the asset (either active or archived).
archived - The timestamp when the asset was archived. This will be empty if the asset is active.
I propose we simplify things by removing the current status field and convert the archived field to a boolean on both assets and plans. I don’t think there is a need to record the timestamp when the record was archived, because this is captured in revisions now (as of farmOS v2).
This is my primary motivation for proposing this. I’ve started working on a custom plan type that provides its own set of statuses, and does not include active as an option (because everything other than archived is technically considered “active”).
I ran into some issues with current code that assumes active will be a valid status.
IMO farmOS should support the ability to have plans with statuses that are more nuanced than just “Active”, so it got me thinking more broadly about what “Status” currently means and what it’s used for.
This is not a perfect solution, but is worth considering if we don’t have the capacity (or consensus) to make this larger proposed change to the data model.
We talked about this on the weekly dev call today (@Symbioquine@Fosten@jgaehring and myself) and were all generally in agreement on the merits of this idea. A couple of notes from the discussion…
We probably should preserve the timestamps that are currently stored in the archived field. We could do this by simply adding a last_archived field and migrating the data into it before converting archived to a boolean.
Perhaps it would make sense to introduce last_archived and immediately deprecate it, with an explanation along the lines of “We’d like to find a better solution to this.” (representing the real world “end” of assets)
Recommend that people who want to keep the old archived timestamp migrate it to a log type that makes sense for them.
@Fosten described how another asset management system (Snipe IT) represents things: a status field with options like “pending/ready to deploy/archived/broken/lost or stolen/out for diagnostics/out for repair”
One potential issue: if we remove status and leave it up to downstream modules to add, then there is a high likelihood that they will conflict (eg: if one adds a status that is a state_machine type, and one adds one that’s a string type).
This is probably more likely on plan entities than asset entities, because plans are almost guaranteed to have a status field with workflow state options, whereas “asset status” is a lot more ambiguous and probably should be more specific than just “status” (eg: “breeding status” vs “weaning status” vs “vaccination status” in animals).
Maybe we move forward with removing status from asset entities, but keep it on plan entities, with a default workflow that contrib modules would be expected to override.
Maybe the default plan workflow only has a single state option: active (which would be a bit weird, and essentially meaningless, but would serve as a placeholder). Or maybe we add some other default states? active + abandoned (like we added to logs)? Maybe also planning to represent that it’s being built but not being actively implemented yet? This is creeping the scope a bit…
OK I’m starting to sketch up these changes in a pull request… and it’s helping me to find other considerations.
I like this idea more and more, and I think having these additional status in the default plan state workflow will be a great addition for plans generally. I’m also thinking about adding a done status, similar to logs. This would allow a plan to go through a standard flow like this: planning → active → done, and could be abandoned at any point.
One small issue that I’m thinking through: if we remove the archived status from plans, and use an archived boolean attribute instead, but we keep the status field on plans, what does the status of archived plans become?
Currently, the archived status could mean eitherdone or abandoned. It’s a bit ambiguous the way it is right now. So we can’t assume that all plans that were archived should now have a status of done, because they may have actually been abandoned (or vice versa). So maybe the best we can do is just set them to active, but set archived to true. Then, if users want to, they can go back in, filter to see archived plans, and update the status to reflect whether it was actually completed or abandoned.
