Create a new architecture for checklists as config entities, with tasks fulfilled by conditions

Thanks, @phenaproxima! Just to document the fact: you and I had a conversation offline in which I invited you to make this proposal.

I like this a lot at the conceptual level. I'm not equipped to weigh in on every detail of the proposed implementation yet. Can you comment on how your proposal might fit into 🌱 [META] Roadmap Active ?

Note: I've created a 3.0.x branch for this.

Certainly.

Add the ability to create/edit checklists via a GUI

This would become a LOT easier to do with a config-based architecture, since there's already a ton of infrastructure in core for creating and editing config entities in the UI.

and export them as features/CMI

If checklists are config entities, you get this for free.

Add the ability to attach (GUI-created) checklists to entities as fields, with display formatters

I think this would be feasible because you could create an entity reference to a checklist (or checklists) with some new formatter that shows it as a progress bar. There is precedent for that.

Add Views support

This goal would be within reach, since Views deals first and foremost with entities. It'd probably take some work (writing the proper Views plugins/handlers), but the use of entities solves a number of foundational problems with Views integration.

Add Rules support, or maybe just some event hooks.

Rules is kinda defunct, no? ECA is probably the most likely successor. Having said that, I know very little about ECA's API but I'm pretty sure we could provide some kind of integration, as long as there's some kind of API for "mark a task as complete".

I'm extremely interested in this. We have a custom "checklist field" I've been using for a while, which is currently a front end built in Vue.js that allows nestable checklist items, each item with the ability to have a note completed by the person using it, a link that may point to a reference page for more info about the task, the checklist state, as well as the "result" - (completed, not completed, not applicable), and the user who checked the box and the time it was checked.

Right now we load the entire thing in a custom field type, which has a single database column -- this serializes the entire checklist as Yaml, which the field formatter loads into the Vue widget, and then uses JSONAPI to update (right now with a save button that re-serializes the entire list and posts it back to the entity). The field widget is just a text area so we can copy/paste entire lists from one instance to another.

We use this for a QA checklist when reviewing new sites, as well as a launch checklist. I also have it on a personal site where I use it for a camping checklist.

The "edit checklist" functionality right now is just edit raw Yaml -- our current UI is ok for actually running down a checklist, taking notes as you go, and outputting a report...

Just providing some ideas of extra requirements to consider for the data model...

We will need config actions in this MVP for recipes to add new tasks.

I should have reloaded before editing.

@phenaproxima (#4) ECA is very easy to add support for, just need to implement plugins as desired.

For events, the easiest thing to do is just use the normal event system, and then an ECA event plugin can subscribe to that.

If everything is in config entities, there may not be anything special needed to work with ECA -- ECA has plugins for entity events, fields, etc.

For this proposal, are you thinking the entire checklist and its state is stored as a config entity? And it contains a list of "task" datatype? Or is there a separate place -- e.g. field data on a field attached to some content entity for the checklist state?

I like that second architecture -- I would like to have a "template" checklist that can be reused a bunch of times. However, I do want to be able to customize the checklist each time it is used. I'm thinking the ideal model for what I'm going for might look something like this:

1. Config entity for the base checklist, containing a set of default tasks
2. Field attached to an entity, which has a "checklist override", and "checklist state"

... the checklist override could suppress specific tasks on the checklist, and add additional as appropriate.

The checklist state would track each task's status -- checked or not, user who checked it, time it was checked, notes, link.

A task (without its state) should also have - label, help text, optional link to instructions.

Is that inline with what's being planned here?

Cheers,
John