Status Conversion on Import Destroys Existing Workflows

[kerim]

Search first

• I searched and no similar issues were found

What Happened?

Currently both TODO and LATER are imported as TODO, and both NOW and DOING as DOING. Also, the WAITING tag has been removed. Since some Logseq MD users used all of these markers, there should be an option to keep LATER, NOW, and WAITING as custom status markers and to create those markers on import if they don't exist.

What this means is that all my workflows are destroyed on import. This is why I have stopped testing Logseq DB, because there is no way to fix this right now. I know I'm not the only one. Import should be non-destructive, and I see the team has already worked hard to fix this for tags, so I hope status import can be next.

Reproduce the Bug

Import a graph that uses something other than a binary NOW/DOING or TODO/LATER workflow.

Expected Behavior

Existing workflows should be preserved.

Screenshots

No response

Browser, Desktop or Mobile Platform Information

No response

Additional Context

No response

Are you willing to submit a PR? If you know how to fix the bug.

• I'm willing to submit a PR (Thank you!)

[kerim]

As a stretch goal, it would be even better if some status markers could be turned to the new "checkbox" property instead of just creating a new status marker. That is actually how I used TODO. In the MD version my custom queries kept it out of my task workflows, but in the new version it will still show up in the default status tables, so it would be even better if it was simply turned into a checkbox instead. However, this may be too much of a niche request, so I'll just be happy if the original request is implemented instead.

[blogbourri]

i agree that:

1. arbitrarily removing task states that were included by default previously is a destructive change that will just introduce friction. this appears to have been done to support what i assume will eventually be a kanban view (the current status set is derived from a kanban workflow), but there must be a better way to do this.
2. a checkbox based workflow is not only simpler, it's honestly more appropriate for the majority of tasks people will do. putting "go to the grocery store" as a backlog is extremely overkill. either it's done or it's not.

my suggestions would be to default to a checkbox based approach. if the checkbox can be made to interface with another property (for example, clicking the checkbox would advance the status to the next value in sequence), that's even better, and i'd probably keep the foundations for a kanban view separate from the task workflow most of us have used for years.

[kerim]

I just did a quick test and found that there current mapping now respects WAITING and CANCELED but still ignores any NOW/DOING or TODO/LATER distinctions.