Option to override default status import options

[wanton rapids]

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.

Personally this request is very important for me, as I was one of those people. Moreover, I created some project management workflow templates that other users found useful and copied, so they will have similar issues to me if this isn't fixed.

[topaz roost]

this was a huge friction point, and the reason i ended up having to make that script to process my graph before importing it, i definitely had a similar project workflow in md version, and would like to see some sort of solve

[wanton rapids]

Yeah, I don't think we should expect users to make or use custom scripts to keep their existing workflows... I personally am especially concerned that such a script might miss something important and I won't know that it didn't get converted properly.

[topaz roost]

for sure, i think at the point where i'm having to write a script something has gone wrong 'cause i'm real bad at that and only go down that road as a last resort heh

i think the biggest challenge the import will face is the extent to which people were using features of logseq in unintended ways

[wanton rapids]

I always hesitate to say what would be difficult or easy from a programming perspective, since I'm not a programmer, but this one seems like it should relatively easy to fix, since there is already an options screen on import and custom status markers are already built in to the new DB version.

[queen roost]

Yeah, people should definitely not have to pull of power user tricks to import their graph successfully. Tagging @spring shore for visibility (though he's at a Clojure conference so might not see it until next week).

[wanton rapids]

I just discovered that there is a separate "checkbox" property which is separate from the "status" property. This is actually how I've been using TODOs in the MD version. What I would really love (but may be too much to ask?) is to map the TODOs on to this checkbox property rather than as TODOs in the status property.

I understand that this may be too much of a niche request, so I'll settle for TODO status - but then I wonder if there will be some way I can search/replace all TODOs to checkboxes after import? That would be ideal...

So, here is an import workflow which would allow me to use the current options, without adding new ones

TODO >>> Checkbox property (not status)
LATER >>> TODO
DOING >>> BACKLOG
NOW >>> DOING
WAITING >>> IN REVIEW (though I really would like to rename this to "waiting" as that is the word I mean, "in review" is just wrong for me, but this would at least work.).

Honestly, it may just be easier to go with my initial request, to create new status options on import, but this way works more closely with how the developers seem to think status should work.

[topaz roost]

check boxes are just infinitely better for tasks that are either done or are not, the idea of running "go to grocery store" through a full kanban workflow is confusing, and the majority of my tasks in md version were mundane like that. if they weren't, i treated them as projects, not tasks. i'm not sure how i'd handle the importing, but this seems sensible enough

[wanton rapids]

Yes, I know a lot of people have tried to use standard markdown checkboxes in Logseq MD, but it never worked well for me, so I just used TODO for that. Having a dedicated checkbox option is a big improvement for me. The only question is how to migrate from one to the other? I really hope the team will give us some more control over the migration process.

[wanton rapids]

I really hope that they do something to fix this. I pretty much stopped testing the DB version a month ago and can't really imagine starting again before I can do a proper import of my existing graph...

[topaz roost]

https://github.com/logseq/db-test/issues/164

i submitted this two weeks ago 'cause i basically stopped waiting for them to implement it, and have instead been figuring out how to make it work how i want it to with the current feature set, but even there i'm running into bugs that make implementing checkboxes for tasks not really work how i need them to. that said, if you aren't using table view, you can just add a checkbox property to #Task and ignore the status workflow entirely.

i think task management in the db version is my one big red flag. it's clear how i think about tasks is very different from how it is currently designed, and i have been bashing my head against the implementation since day 1

i think to get 1:1 feature parity, without them implementing it, there would need to be a way to make the checkbox not just toggle states, but cycle another property through a list of values.

[tacit grove]

DOING >>> BACKLOG ? Why is that?

[wanton rapids]

I think they have a "doing" option now. I haven't tested things lately...

[topaz roost]

i'm not clear what you're asking here

[tacit grove]

To @wanton rapids , about the suggested workflow here #1298107981463818293 message

[topaz roost]

got it

i know luhmann and i both were using now/later and todo/doing fairly idiosyncratically. i was using DOING for projects, LATER for review, and NOW for tasks (and not cycling through the task states for them ... it was basically just a quick way to get a check box). so it might be to do with what they were using DOING for.

[tacit grove]

I'm using DOING only for "ongoing" #project instances, in my case. My comment was about targeting to BACKLOG, which I understand, from an Agile point of view, it is a status for non-activated items, therefore is not DOING.

That's my current MD workflow

[wanton rapids]

I don't really care what they call it, I just object to having multiple categories merged into one on import. It is the distinctions I want preserved not the particular name.

[tacit grove]

Semantics is also important if we want to fit as many workflows as possible when importing, not just distinguishable categories.

[wanton rapids]

OK. It seems that this issue has actually been fixed. After spending a few hours trying to test import I discovered that my request has actually been acted on, even though I didn't get notification that this was the case. CANCELED and DOING are now preserved. I assume that NOW and LATER are as well, but because I converted those manually I can't be sure.

Can someone help test? I already wasted half a day just to find this out...

https://discord.com/channels/725182569297215569/1316987610656145518

[wanton rapids]

I did a quick test today.

TODO > Todo
NOW > Doing
DOING > Doing
LATER > Todo
WAITING > Backlog
CANCELED > Canceled

So it still doesn't respect NOW/DOING or TODO/LATER distinctions, but WAITING and CANCELED are respected.

[wanton rapids]

It is necessary to distinguish between (a) feature requests to the developers for how things should work in the final product, and (b) efforts by users to shoehorn their existing workflows into an alpha product that is undergoing rapid development and where the developers are prioritizing working on certain features rather than others. My comment was discussing a possible solution for (b), but I don't disagree with your statement with regard to (a). In fact, however, my workflow doesn't work for (b) either, which is why I am now trying a different method of tagging items as #inprocess for genuine "doing" items, to distinguish them from NOW imports which are also treated as "doing" by the current import settings.