Task types

[Dym03]

Added Task types for possible sorting and grouping of the tasks. Enums are solved using a django_enums, could lead to easier comparison of enums.

Fixes: #578

[geordi]

Thanks for your contribution! Please, try to squash a few commits.

[Kobzol]

For review it's easier to see the individual changes, so you can keep it like this for now. I'll try to take a look soon-ish. Thanks!

[Kobzol]

Thanks a lot for the PR! It looks really good, and would already provide value to us. I left some comments on things that I'd like to change.

[Kobzol]

If the type will be invalid, this will end in 500 server error. Let's check if the type is valid based on the TextChoices values, and if not, return a proper 400 bad client request error.

[Dym03]

I have hopefully resolved all of the problems mentioned in the feedbacks. Only problem with the null values are in the admin page, where they are now required, and i wasn't able to add an option with null as an option, this could be solved with adding a blank=True in the definition, whereas this would provide null as a default option. This depends on you.
Small frontend changes were made, preview can be seen on the next picture.

[Kobzol]

Sorry, that was a small misunderstanding, we didn't necessarily want to have all the types from Edison, just wanted to point out which ones exist :)

I would go for this set, to make it simpler than Edison:

HOMEWORK
PROJECT
EXAM
LABORATORY
OTHER

I played with this locally a bit and I have to say that I'm a bit worried about the usage of the enum. It's quite strict and if we ever rename one of the fields or somehow wrong stuff appears in the DB, the server will not have a good time. We could work around that using type = EnumField(TaskType, null=True, constrained=False, strict=False), but at that point we might just as well use a string. This kind of usage also has a big disadvantage in that it changes the field type - if there is an unknown value, it will be a string, while if there's a known value, it will be an enum instance, which is super confusing and error-prone.

I would just use a normal string, as we do for the existing enums (e.g. Day). With TextChoices, it's relatively easy to work with them even in the admin. It cannot be reset to NULL in admin, but we don't really ever want to reset the type to NULL after setting it for the first time anyway.

[Dym03]

Okey, it was not specified, so i added all, but got it, will update that. About the enum thing, i didn't test it that much, but it was only proposed solution. After all the Enum is to my understanding just a wrapper around the choices, so i will change it. Is it a wanted feature to be able to leave a new task without a task type or to leave it blank. Or every new task created in the admin should have a type ? @Kobzol

[Kobzol]

The enum was a good idea, but I worry that with our state of the database in Kelvin it would be a bit too easy to get into some weird state, and then the website would essentially become bricked until someone updated the DB manually to fix the invalid enum values 😅

We don't really create tasks in the admin, so it's not super important how it behaves there. For creating tasks on Kelvin, on the EditTask page, I would like to uphold the following rules:

• If a task is being created, the task type has to be set (the default should be prefilled e.g. to "homework")
• If a task is being edited, and the the task type was NULL, it can remain NULL when the task is saved
• If a task is being edited, and the task type was not NULL, it shouldn't be possible to set it back to NULL again

Does that make sense?

[Dym03]

Makes sense. Will try to implement this behavior :). Thanks for the clarification. I wasn't sure where the task where being created, now that is clear.

[Dym03]

Should be ready for merge now, squashed down into two main commits for backend and frontend.

[Kobzol]

Thank you! Left two minor comments, otherwise it looks pretty good :)

[Kobzol]

Awesome work. Thank you very much! ❤️