Checklist Plugin - Interactive Checkboxes made Simple

(cpradio) #1

I’m happy to announce that I’ve ported the checklist plugin created by @lightyear to run on the latest version of Discourse.

You can find the new repo at GitHub - discourse/discourse-checklist: A simple checklist rendering plugin for discourse

With this release comes a few enhancements.

  • You can disable the plugin in its entirety from the Admin > Settings area (strike through still gets processed, but the checkboxes won’t render and won’t be clickable)
  • You can keep checking/unchecking boxes on the same post without having to refresh the page.

Any issues should be reported either here or via a GitHub issue. I also welcome translation file PRs, or general enhancement PRs.


see: Install Plugins in Discourse

Repo is:

Task manager within Discourse?
"I read it" button alongside "I like it" button?
How to install a plugin on Discourse-hosted-Discourse?
Any way to have a single option poll with just one option to choose from?
Task manager within Discourse?
Quick Messages Plugin
How to create organized markable list?
GitHub-style task list
No way to install markdown-it plugins?
Discourse 2.1.0.beta5 Release Notes
(Nukeador) #3

Thanks for this, it’s really useful for teams that use discourse to track bugs, features or plans.

(Marco) #17

Thanks @cpradio I have installed this plugin on my site and work very well :slight_smile:

1 Like
(Joe Buhlig) #43

Is it possible to set this up with the ability to check/uncheck all in a list at one time? I have a scenario where a checklist is reusable but it’s a pain to create the same list multiple times. Being able to do a one-click and reset a list would be extremely useful.

1 Like
(cpradio) #44

Edit the post? Apart from that, there currently isn’t.

(Joe Buhlig) #45

My current method is to do just that. Copy the whole thing, drop it in Sublime, select all instances of - [x], and edit them all at once. I just wondered if this was in the plans or not. :wink:

(cpradio) #46

Not in the current plans, I’m not even sure what that would look like (as I’m not really sure as to what the actual need is or why the need exists, adding a “select all” above/below the list seems noisy and likely unwanted in most cases). However, I’m open to a PR for the feature so long as it sits behind a site setting, as I feel it is probably a power-user feature.

PS. I’d look into implementing it myself, but I’m in the middle of moving and my full time job has me swamped (and has had me swamped for months!), so the free time I do have is mostly spending time with the family.

(Jeff Atwood) #47

I wonder if we should adopt this and make it first party @sam? Any preference? It comes up in GitHub issues conversions.

(Sam Saffron) #48

I am more than happy to adopt this, I do find I want to use it in our private instance sometimes.

(cpradio) #49

That would be a dream! :heart_eyes:

I’m glad this has solved a need for many.

Just let me know what (if anything) you need from me. I can transfer the repo, or if it is me updating the readme and repo to be blank so it doesn’t interfere with it moving to core.

(cpradio) #52

Transfer completed. Updated the first post with the new Repo URL.

Edit: Err… well this is embarrassing… I can’t update the first post :slight_smile: @sam would you kindly do it?

(Sam Saffron) #53

I wikified the OP so you should be all good, plugins is marked official per:

(Evgeny) #65

What are the correct actions, for example, for this case? Create a language file inside the plugin (client.en.yml), or add a translation to common language files?

This applies not only to this plugin. I’m just curious about the future. If, say, there is only one line of text, it makes sense to make language files?

(Sam Saffron) #66

@neil should be able to help out here, we have a new process for translating core plugins that involves having them in transifex.

Step #1 though is getting the English translation file.

(Neil Lalonde) #67

Translations have been added to Transifex.

(Evgeny) #68

Hmm. And the file: client.*.yml for translation should be created or translated (checklist change) will be taken from another location?

(Neil Lalonde) #69

There is no client.*.yml file though… :thinking:

(Evgeny) #70

So I’m interested in how to act in such conditions in the future. If there is only one phrase for translation. Whether it is worth doing many files for the plugin or you can use the translation from another location. Say, by adding it to the main file a language file: discourse/config/locales/

(cpradio) #71

Sadly true. This is one of those things I thought I fixed a while back, but I must have never committed it. I do recall a discussion on it in the past though.

I imagine they would accept a PR that added the client.en.yml file and translated that string.

(Mittineague) #72

I know, (or maybe more correctly, knew), how to use translations in plugin template files.

I am sure that editing the
edit_reason: 'checklist change',
line of the initializer file is not the best way.

Unfortunately, other than pulling in site-settings:main, I do not know how to pull in the client or server yml so the values can be used in the initializer.