show-resolved shows UUID, can use edit/modify/notes command resolved tasks

[ard0gg]

This is a work in progress. Edit: Addresses #18 I've modified the show-resolved display to also include the first 8 digits of the UUID in the first column. As shown below:

> Week 29, starting Tue 14 Jul 2020

UUID      Resolv  Pr  Tags  Project   Summary
a0a66fef  Tue 14  P2  work  12button  pull part numbers for design
a7813a92  Thu 16  P2  work  #####     release BOM/Scheamtic


> Week 30, starting Mon 20 Jul 2020

UUID      Resolv  Pr  Tags  Project   Summary
e4998b2b  Mon 20  P2  work  12button  pass schematic off to doug
caf99371  Mon 20  P2  work  12button  review schematic
9bd43844  Mon 20  P2  work  rgb       release Master schematic/BOM
5b04a0ac  Mon 20  P2  work  rgb       release slave schematic/BOM
39eba78c  Mon 20  P2  work  amp       perform troubleshoot update
5a86a39b  Mon 20  P1  work  12cpm     Finish DFMEA
7e32a1d4  Mon 20  P1  work  qhb       complete DFMEA
93ec556d  Tue 21  P2  work  qhb       update specification
931b58fc  Wed 22  P2  work  qhb       review DFMEA
9bc83c4d  Wed 22  P2  work  12cpm     review DFMEA
2eec2e8a  Thu 23  P1  work  12cpm     Release DFMEA
c3c825eb  Fri 24  P2  work  12cpm     modify d6 to match QHB
14 tasks.
Active context: +work

Additionally added the ability to edit resolved tasks by using the "uuid:" modifier with the edit command. I'm not sure if this is the best command to use. Would it be better to use notes or modify? Or have the capability to use those commands in addition to the edit command?

Right now only resolved tasks can be found using the "uuid:" tag.

CMD_EDIT will check if the command line includes a UUID and load resolved tasks if so. It will then check to see if it can match the user entered UUID with any resolved tasks. If only one matches, it is edited. User is prompted if no UUIDs are matched:

ard0gg:~/src/dstask/ard0gg$ task edit uuid:5adfaddfa
No Resolved Tasks Match UUID: 5adfaddfa!

or more than 1 UUID matches. In the case that more than 1 UUID matches, the matching UUIDs are listed. Right now the display of the tasks is hard coded in CMD_EDIT. Would like to be able to use filters/functions in display.go eventually.

ard0gg:~/src/dstask/ard0gg$ task edit uuid:9
Multiple Tasks match UUID: 9

UUID                                    Summary
915cb9f5-0ee4-4824-a865-e98830f7c8f4    add switch for BL PWM
931b58fc-e0da-4de0-828f-5ab7485d8dc3    review DFMEA
93ec556d-ab8e-40c3-97e1-a4782813e288    update specification
9bc83c4d-f39d-4689-8609-87227da7bbcf    review DFMEA
9bd43844-9cdf-487d-8b39-b46c164a0122    release Master schematic/BOM

Provide provide more specific UUID

Completion of "uuid:" works for edit iff there are no IDs in the command line. However, there is the issue where a space is presented after "uuid:". I'm not intending to include completion of the task.UUIDs.

[naggie]

Nice -- this is how I was planning to implement it too. Though, I had thought we could do it without the uuid: prefix; the parser would match on anything that looks like a UUID4 substring of more than (say) 4 characters with the listing disambiguation mechanism.

Of course this would produce some false positives sometimes (when searching for a string) though I'd wager rarely, but the result may be benign. I'm definitely on the fence though, I think this is something that requires experimentation.

I think all of note/modify/edit are suitable. I appreciate this may result in a bit of copied code around, I plan on factoring the big switch statement that the CLI interface has by generalising the normal views etc.

[dontlaugh]

On the question of using a uuid: prefix vs. automatic detection of uuid, I would vote for keeping the prefix.

1. if a prefix aids in writing the command line completion scripts, that seems like the bigger benefit
2. automatic detection of UUID could always be added later

[naggie]

On the question of using a uuid: prefix vs. automatic detection of uuid, I would vote for keeping the prefix.

1. if a prefix aids in writing the command line completion scripts, that seems like the bigger benefit

2. automatic detection of UUID could always be added later

Ok, I think you've persuaded me with the command line completion point. Though, it will be slow if we're completing for resolved tasks (probably the primary use case for addressing by UUID).

Caching resolved UUIDs might be necessary but I'd like to avoid that unless there's no choice. Once the OS caches the files, loading all resolved tasks is fast enough so far.

[ard0gg]

Ok, I think you've persuaded me with the command line completion point. Though, it will be slow if we're completing for resolved tasks (probably the primary use case for addressing by UUID).

So are we thinking supporting UUID only with a "uuid:" tag or would we still like the parser to try and match anything that looks like a UUID4 substring as well?

[ard0gg]

Thank you @dontlaugh and @naggie for the review. I really appreciate the feedback. I will work on incorporating the suggestions you've made.

[ard0gg]

Another question I had.... Do we want to allow for status of resolved tasks to be changed?

[naggie]

So are we thinking supporting UUID only with a "uuid:" tag or would we still like the parser to try and match anything that looks like a UUID4 substring as well?

I think we should go with your idea of just having the uuid: prefix having thought about it a bit. I think it's natural syntax, given you can query with project: too.

Thank you @dontlaugh and @naggie for the review. I really appreciate the feedback. I will work on incorporating the suggestions you've made.

No problem, thanks for putting the effort in. I'm really pleased to see contributors + users!

Another question I had.... Do we want to allow for status of resolved tasks to be changed?

I think definitely -- it could be useful and we can just add it to the valid status transition list: https://github.com/naggie/dstask/blob/2cee8103519c1fd1a4d0e25d263be7689241c1e8/const.go#L115 (consumed in util.go by IsValidTransition)

[ard0gg]

Looking for thoughts on resolving partial UUID4 strings. I now have completions working for the commands Edit/Modify/Note when an ID is not present in the CmdLine. Do we want to rely on completions to fill in whole UUID4 strings?

[naggie]

I think that UUIDs are only likely to be used to reference resolved tasks, given the convenience of numeric IDs as well as the fact that no current non-resolved view shows the UUIDs. Given the performance implication of autocompleting non-resolved tasks, I suggest we just don't do it.

The disambiguation system that shows the matching prefixes is a good compromise in my opinion.

[naggie]

I think that UUIDs are only likely to be used to reference resolved tasks, given the convenience of numeric IDs as well as the fact that no current non-resolved view shows the UUIDs. Given the performance implication of autocompleting non-resolved tasks, I suggest we just don't do it.

The disambiguation system that shows the matching prefixes is a good compromise in my opinion.

Oops, I meant resolved tasks -- completing non-resolved tasks is fine as the number of non-resolved tasks is generally stable -- resolved tasks keep adding up forever, and aren't generally loaded into the OS disk cache as they're only loaded for various reports.

(EDIT: Also I just saw @dontlaugh's point about listing the directory -- UUIDs, even resolved can be completed quick if the tasks aren't loaded. In any case, benchmarks with a dropped cache are probably necessary to determine what's best)

Regarding processing UUIDs: generally speaking, once tasks are loaded iterating over the tasks to aggregate things isn't expensive. I deliberately haven't attempted to optimise aside from not loading resolved tasks all the time.

---

I'll leave you both to the discussion and implementation if that's OK (considering the effort and thought going into it, thanks) as we've just had our second baby a few days ago so no time :)

[dontlaugh]

CONGRATS!!!! :blush:

[naggie]

Thanks :)

[ard0gg]

Congrats on the new baby, Naggie!

Thank you both for taking the time to review. Sorry I've also not had much free time lately, but I plan to take a closer look this weekend.

[naggie]

Thanks @ard0gg :-)

No need to apologise, nor any pressure :+1:

[cgardner]

It seems like there are some conflicts in these changes now.