[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?