What happens if you try to delete a challenge task ? (very low priority)

[LordVladneutral]

I like to mess around with programs and to test their limits. You cannot normally delete a task from a challenge, but in habitican-curse you can flag it for deletion, and that gets you this error message (when you try to write the changes) :

python2.7 habitican-curse
Traceback (most recent call last):
  File "habitican-curse", line 54, in <module>
    curses.wrapper(main)
  File "/usr/lib/python2.7/curses/wrapper.py", line 43, in wrapper
    return func(stdscr, *args, **kwds)
  File "habitican-curse", line 48, in main
    G.intf.Input()
  File "/usr/lib/python2.7/site-packages/habitican_curse/interface.py", line 354, in Input
    self.Command(command)
  File "/usr/lib/python2.7/site-packages/habitican_curse/interface.py", line 262, in Command
    G.reqManager.Flush() #Send the queue
  File "/usr/lib/python2.7/site-packages/habitican_curse/request_manager.py", line 320, in Flush
    self.DeleteTask(i.task.taskID)
  File "/usr/lib/python2.7/site-packages/habitican_curse/request_manager.py", line 123, in DeleteTask
    return self.APIV3_call("tasks/"+task_id,method='delete')
  File "/usr/lib/python2.7/site-packages/habitican_curse/request_manager.py", line 73, in APIV3_call
    raise ValueError("HTTP Response not recognized: %d" % resp.status_code)
ValueError: HTTP Response not recognized: 401
python2.7 habitican-curse  7,42s user 0,70s system 0% cpu 5:33:29,51 total

Of course nobody should do that, I certainly won't do it again, but in case, there are two fixes you can make for this :

• You make a proper error handling so the program doesn't exit and says one task cannot be deleted because it is from a challenge.
• Or you prevent tasks from challenge to be flagged for deletion (but that would require the program to know if a given task is from a challenge or not to begin with). Looks a bit harder to code, but possible.

This is how I see it.

[rbavishi]

@LordVladneutral Good Catch! Error handling in the requests module would be clumsy and prone to bugs. The API is very well-crafted, so figuring out whether a task is from a challenge is pretty easy. The code was modular enough for me to incorporate the changes without any hassle.

I've added the feature and packaged it up on PyPi. Can you do a pip install (again :) ) to check it out?

[rbavishi]

Also check out the updated README. Documentation on the task-modification functionality has been added. More detailed documentation can be accessed using :help inside the program.

[LordVladneutral]

So, the flagging for deletion now does not affect challenge to-dos and a little message appears on top of the screen, it looks perfect.

I checked the documentation, the new functions look neat, I am thoroughly testing them and I'll report anything I find.

Actually I found something already. If you try to set a due date to a challenge to-do (which is only doable by the challenge maker in the challenge creation interface.) the to-do will appear to have the due date, while no changes are applied on the normal Habitica interface, even if you :w your changes. The due date disappears when you :r the curse interface. Ideally, challenge to-do should be excluded from the "set due".

The same thing applies when you try to change the difficulty of a challenge task, it appears on the curses interface until you :r it and it goes back to normal. Also same thing when you change the frequence of a challenge daily.

The problem seem handled when it comes to direction for challenge habits.

I also noticed that :r without doing :w before writes the changes anyway. The way I see it working, there should be a way to just get an update while conserving the change unwritten, and also a way to completely erase all changes made and get the current state of the server.

Also :r is undocumented in the :help page.

Other than that the new features work perfectly as expected.

[LordVladneutral]

Also, I wonder : I have a list of 100+ to-do and 50+ of the other kinds of tasks, but they appear in what seems to me like completely random order, is it expected behaviour ?

If yes, could it be maybe a little better handled ?

If not, is there an error message I can get you to work with ? How do I provoke it ?

[rbavishi]

I've added functionality that prohibits a change in parameters such as difficulty etc. for the challenge tasks. I've also redefined the functionality of 'r'. It prompts you if any writes are pending. Using ':r!' will ignore all the edits as you suggested. Do a pip install again please.

About the order, it's strange that you're getting an unexpected one. I'm processing the tasks in the order they are presented to me by the JSON response from the server. For me, this is matching the one used on the site. What ordering would you prefer?

[LordVladneutral]

All the new features tested, all working as expected.

Ok, so this is unexpected behaviour. Before anything, I might know why this happens this way so I'll check that. If it's not this, then we'll see.

[LordVladneutral]

Maybe it's because of this bug (that will soon be corrected) or maybe it's something else, probably because my task list is so big, but it really seems the .json file just gives tasks in random order. Any order would be preferable to that, and as the .json doesn't seem to give an "order" info on tasks, creation date or value are my preferred sorting values, if it is needed to use something to sort them.

A :sort feature might be an idea. Or a preference in the file where the ID and API key are stored, or both, to set the preferred variable as sorting key. Like that it is only for those who do have random order and the others keep json/habitica order. On a sidenote, even without such randomness this is a handy feature to have.

[rbavishi]

I see, I'll start working on the sort feature, will let you know. Thanks!

[LordVladneutral]

It does not change anything that the minor bug in my list. The Json order is still seemingly random.

[jasonuher]

I'm going to break this out into separate issues and ask @rbavishi to close this one so they can be tracking atomically.