CLI prioritization/order/frogs

[ctengel]

Related to #55 ?

[ctengel]

we need prioritzation to work like so

0. Reserved
1. ordering LSB (1 is higher)
2. ordering MSB (1 is higher)
3. priority LSB (0=B_, 1=AC)
4. priority MSB (0=C_, 1=AB)
5. if 6 is:
   • 0 (not unstaged)
     • 0=normal, merged in from later date
     • 1=higher, merged in from higher date
   • 1 (unstaged)
     • 0=normal, manually individually unstaged
     • 1=higher, bulk unstaged (like at end of day)
6. unstaged, i.e. 1 if the task had been staged and was unstaged
7. reserved

pri up increases the 3&4 bits (none=>C=>B=>A) but does not change the others

• if A, use 2-1 to increase

pri down zeroes out 7-5, 3-0

• if any of 7-5 are 1, treat as A and push to baseB

stop using wakeup as a way to prioritize

[ctengel]

ensure it is available from API - probably is!

[ctengel]

For now implement in client library

[ctengel]

Problem: above description shows priority with 0 as lowest and 255 as highest (descending), but API currently has it implemented ascending

[ctengel]

Currently it is not used anywhere - it had been in legacy, but not in current.

Currently it is again ascending (i.e. lower integers are highest priority)

Other curveball - sqlite considers null to be LOW, whilst postgres considers null to be HIGH

Default is Null and I think we would want default to be low. We can work around by explicitly asking NULLSLAST or setting default=0

[ctengel]

The simple answer for now - modify the api to do desc and rely on sqlite, with more explicit if/when we move to postgres

(note FROG is considered more important than PRI, but not much else)

[ctengel]

Still needed

• [X] client library implementation
• [ ] formal document
• [ ] issues/plan for DB flexibility (i.e. don't assume sqlite)
• [ ] issues/plan to move to API