[META] Roadmap

I think the most effective way to accomplish this is by moving to entities. That is, define a 'checklist' entity-type, with custom fields for checklist items, completion time-stamps, and other options. Presumably, we could leverage existing fields for more standard things like titles, descriptions, field groups, etc.

Entity bundles would then represent a given defined checklist (e.g QA checklist), which via Entity API (for D7) can be exported. Entity API also provides built-in Views and Rules support, and an admin UI. Attaching checklists as fields would presumably be simpler than is currently in #2056411: Attach checklists to entities as fields, as we shouldn't have to handle saving/loading them ourselves.

I really like the existing checklist alter hook. We should try to ensure that Features Override, or some other solution can provide us with similar capabilities.

This should satisfy all the features listed above (except the 8.x upgrade). However, since all this is a major API change, I would suggest moving it 7.x-2.x and 8.x-2.x branches.

I've been looking into the Checklist API implementation and how the PASC and QA checklists pile up. What's your opinion about the following?

At admin/config/development/ you seem to have direct access to any checklist that has been created. If you do end up with many checklists (who knows the complex use cases people can sometimes have...) I wonder if only having them under admin/reports/checklistapi instead would be okay from a UX POV? Seems like this would thus be very straightforward to have any number of predefined checklists (PASC, QA, SEO, your own...) and a button for adding any custom checklist that you would want to create there. Here's a sample mockup:

I'm strongly advocating too for a fieldable entity structure to move away from checklists in code and allow site builders to create their own checklists. With CMI in D8, this is even more easy to achieve as enabling the module could simply copy over predefined YAML configuration files (under config/) without writing any line of code.

Oh, and FWIW I also really like the idea of having a per-node editorial checklist, too.

Hi,

Just stumbled across this module, which looks like a great starting point for what we're trying to do - streamline maintenance across a bunch of sites. In addition to the two user scenarios discussed, which I think are great, what I'm looking for is quite a bit more complex -- the ability to manage collections of checklists.

We would use this in a project management site (OpenAtrium), not on the individual sites. So what I'm looking to do is have essentially an object-oriented, inherited model for checklists.

For example, we might have these base checklist "bundles":

- Launch checklist
- Monthly Maintenance checklist
- Site assessment checklist
- Theme builder's checklist

Those would have a base set of tasks/checkboxes for all descendent checklists, all sites.

When adding a new customer, we might need to tailor the checklists, adding some items that are specific to that site. In particular, a monthly checklist we would add a new node, with a new copy of the checklist, that should have the site-specific version of the checklist with some items added and other removed from the base checklist, but the same set of items as were in the previous month...

... and then to take that one step further, if we add an item to the base monthly maintenance checklist, have that item appear on all new checklists for all the sites...

Does that make sense? Have not tried out the module yet to see if the data model will support this type of scenario, but I thought I would add this as a hugely desirable feature. And if appropriate, we might be willing to contribute some development towards this.

Hi, Travis,

Ok, I've started commenting on this architecture discussion twice, in two completely different directions... what a thorny data modeling challenge!

Scrapping all that, two thoughts:

1. I'd like something integrated with Paragraphs module, so I can pull a checklist into a document structure wherever I want it. OpenAtrium has done some cool things with custom Paragraph bundles -- snippets, related content -- that might provide some good models.

2. I think when it comes down to it, however we choose to store it in the back end, I'm seeing the need for two different classes of objects here: a "template" checklist, and a checklist "instance". The thing is, every checklist "instance" may end up entirely unique, and should be possible to edit/change well beyond the original template. And I would want to be able to define different behaviors linking templates with instances -- e.g. when I add an item to this template, (add/do not add) this item to all (existing/only new) checklists based on this template (also need to consider updates and delete).

Not sure how to take it from there, just getting down some further thoughts...

Cheers,
John

I'd use a Template-Instance setup. Not saying it's easy to build, but sounded good.

+1 for checklists as entities. This issue outlines the use-case I am working towards (as well as integration with the Log record keeping module): #2876152: Integrate with Log module

I'm a bit on the fence about whether they should be content entities (fieldable) or config entities (not fieldable), however. In my case I will need to create pre-defined checklists that will be the same across hundreds of sites. I could use some kind of content export/import to achieve that, but config entities already work the way I need.

And with checklists available as fields (#2056411: Attach checklists to entities as fields) they could be added to content entities (ie: nodes), while referencing the underlying checklist config entity. If we integrate with the Log module, and create Log entities when checklist items are checked off, then we could offload the storage of date and "done/not done" to that module instead of storing it in this module.

So: Checklists would be config entities, there would be a "Checklist" field type that could be added to content entities which references a specific checklist config entity and displays it when you are viewing the content entity, and when you check items off as "done" it creates Log entities in the background (and links them to the content entity via a reference table so that you can click through to them for more details).

Maybe that's a bit off on a new tangent... just throwing some ideas out there... what do you think?

Ah on second read-through I think I understand @ergonlogic's suggestion for a checklist content entity a bit better. Each bundle would define the individual checklist items as fields, so the bundle config could be exported and shared across sites. That would work for me!

How would the fields themselves work? Would they be a new field type? I haven't reviewed #2056411: Attach checklists to entities as fields, but would it be different from that?

I'd like to help get to a 3.0.0 release, but I'm struggling to figure out how to contribute effectively.

Looking at issues for 3.x (aside from this one), we have:

1. A re-architecture plan in #3474212: Create a new architecture for checklists as config entities, with tasks fulfilled by conditions, of which a lot of progress has already been made in:
1. #3474237: Create a new Checklist config entity type
2. #3476269: Checklist tasks should be content entities
2. #3475410: Convert storage backends into plugins
3. #3477079: Create a content entity type to track the state of a task, and its history of state changes

It seems to me that there are a number of gaps in terms of describing a reasonably complete 3.0.0 feature set. What we envision that to be is still a bit unclear to me as well. I think a lot of this is described in those tickets, but sometimes implicitly, or embedded in a discussion on architecture and implementation decisions.

I'm planning to re-read those tickets, and try to consolidate some clear use-cases and attempt to document some more narrowly-focused feature requests, to help flesh out the roadmap.

From a review of open issues, and especially #3474212: Create a new architecture for checklists as config entities, with tasks fulfilled by conditions, here are some use-cases:

From @freelock's comment (#6): 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. Current features of bespoke field implementation:

• 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)
• the user who checked the box and the time it was checked.

From @freelock's other comment (#9): 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. Suggested implementation:

• Config entity for the base checklist, containing a set of default tasks
• 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.

From #3474212: Create a new architecture for checklists as config entities, with tasks fulfilled by conditions, the primary use-case is: "manage checklists, for administrative dashboards [...] favoring recipes, which are ways to share config."

Features and implementation (mostly from various comments by @phenaproxima):

Completed features in 3.0.x:
✔ "Checklist config entity type" Satisfied by #3474237: Create a new Checklist config entity type
✔ "Task value object" Satisfied by #3476269: Checklist tasks should be content entities
✔ "optional set of conditions to programmatically determine if the task is completed or not." Satisfied as described in comment #6
✔ "Config actions [...] to add a task to a checklist from a recipe" Satisfied by #3476269: Checklist tasks should be content entities?

Current work-in-progress on storage plugins (see: #3475410: Convert storage backends into plugins)

☐ "[Storage plugins] store the state of checklist tasks, and fetch that state upon request. The state, for what it's worth, is just an arbitrary string. [...] It has nothing to do with state management or progress storage. We'll do that in subsequent issues."
☐ "[Task state] is just an arbitrary string. The idea is to eventually map it to states defined in workflow config entities. [...] The semantic meaning of any given state -- as in, does this state indicate that the task is complete, incomplete, or not applicable -- is not determined by the storage plugin. That will be dealt with in another issue"
☐ "Storage plugins should also have the ability to clear the stored data for a given checklist. They should NOT have the ability to report on or compute overall progress; that ability will live in another, separate service."

Additional functionality that (probably) require new feature requests:

☐ "Progress service which [...] can tell you whether [a checklist] is complete"
☐ "[field] formatter that shows it as a progress bar"
☐ "progress bar rendered in a block associated with a particular checklist"
☐ "a way to create checklists in the UI"
☐ "[Remove] current hook-based checklist definitions and API" New task?
☐ "Views integration"
☐ "event hooks."
☐ "API for "mark a task as complete"." (Maybe via ECA integration)
☐ "you can add task groups and tasks, but currently there is no way to remove any of those things."

I'm not sure to what extent the above is helpful, but it's the best I could wrangle out of the current issues.

Perhaps maintainers could discuss, agree on a feature-set for 3.0.0, and update the issue description, etc.