Add checkbox not working

Steps to reproduce

Starting from scratch, what are the steps to make the bug happen? The fewer the steps, the better.

Open menu in any item
Select Add checkbox

Expected result

What do you expect to see after carrying out the steps above?

Add checkbox for the item

Actual result

Instead of the expected result, what happened?

Did not add checkbox for the item


Which operating system are you using?
Which browser are you using?
If you’re using a desktop or mobile app, what’s the version number of Dynalist?
Are you using any third-party scripts for Dynalist, e.g. PowerPack?

Windows 10 / Google Chrome

Additional information

Anything else you think would help our investigation, like a screenshot or a log file? You can drag and drop screenshots to this box. For large amount of text, try putting them into something like Pastebin.

Use shortcut work, but I usually don’t use shortcut to add checkbox
Add checkbox to children work

Additional comments

1 Like

I’m having this issue too (Windows 10 / Chrome). It also can’t remove checkboxes from existing items.

The only thing that’s working is “Add checkbox to children”, but this adds a checkbox to the parent item as well, so if I can’t remove the checkmark on the parent then I can’t make the list look the way it did before the change:

Sorry Erica/Shida, but this is a mess. The way this has been implemented seems to have caused all sorts of problems. Yes, I’ve seen the info in the PSA but I can’t believe that this couldn’t have been done differently. I’ll file bug reports separately if I can’t resolve. :slightly_frowning_face:

I’ve suggested in a previous thread that a lot of these issues could be avoided if you have a beta group. I know there are only two of you but, to me, this is all the more reason to test with user assistance prior to release.

As noted by @KC , I am able to add/remove the checkbox using ctrl+shift+c, however the “Add/Remove checkbox” option in the item menu appears to be non-functional. I didn’t realize the keyboard shortcut was functioning properly before as I have an AutoHotKey keybinding already bound to ctrl+shift+c.

Can repro, will fix asap. @Jayden_Navarro thanks for the tip on shortcut, that helps nail down the issue.

Apologies for the issues. Could you explain a little more what you mean by “The way this has been implemented seems to have caused all sorts of problems.”

For now the rollout process involves pushing the web app. It’s done on a weekend usually to avoid workflow disruption for most people. We’re available for the next few days to observe any critical issues before the new build is shipped to mobile and desktop app.

I’m completely for the idea of having a beta group, but right now our setup makes it a little difficult to host 2 different builds at the same time and selectively serve them to users.

Update: Fix is now live, reload to get.

1 Like

Apologies for the issues. Could you explain a little more what you mean by “The way this has been implemented seems to have caused all sorts of problems.”

Well, some have already been reported, but a quick example of another problem is that the custom css code I use to avoid display of both a bullet and a checkbox has stopped working: -

/* dont render bullet if checkbox exists */
.Node-outer > >
.Node-self > .Node-bullet {
display: none;

I’m a bit confused. Does this mean you don’t do any pre-release testing yourselves? I would have thought the bug reported by @KC would have been picked up immediately with basic testing.

I’m sure you’re tired of being referenced to Workflowy, but how about adopting their approach of giving new functionality a beta toggle within the main app, that you have to opt in to try. Essentially, this is what Google did too for years with Google Labs functionality in their main apps.

Yeah we do several rounds of internal testing, but it seemed like it was broken last minute because a small code rename after we tested the functionality, d’oh! On top of that, for this round of release, most of our efforts were focused on making the date range interface work smoothly. While the changes for the checklist/checkbox have big impacts in terms of usage, code changes were actually very little.

I can imagine that works well for some functionality, especially things that only affect visuals or how things are displayed, for a single user. Anything that touches data or markdown encoding formats we would need to deploy to everyone (sometimes even in advance) because of the possibility of shared documents and multiple device usage.

I think right now what we would do is to use a preference to gate whether some functionality is on or off, just so users have a choice (especially if the functionality is only useful to some users).

Just want to make it clear that I’m only trying to explain the situation that lead to this bug. We have no excuse for this to happen and we’re very sorry!

Again, I completely agree that the release process has lots of room for improvement. We’re only trying to work around the current situation without complicating the codebase, and if any mistakes slips through, we hope to make up to it by being available and responsive with a fix.

Apologies for not handling this better. I hope we didn’t ruin your day because of these issues :cry:.

No apology necessary. Just want the best Dynalist possible - which you usually give us. :wink:


Ok. I think this revision fixes it.

/* dont render bullet if checkbox exists */
.Node-outer > .Node.has-checkbox >
.Node-self > .Node-bullet {
display: none;

Not on mobile at least.

If you’re on Android the update has already been released. iOS is still waiting for review.