Make Task Model Fields Editable on Frontend and Backend

[its-me-abhishek]

Description:
Currently, the Task model has several fields, but not all are editable consistently. Some fields are editable only on the backend, some only on the frontend, and some aren’t editable at all. The goal is to make the as many fields editable on both frontend and backend as possible (some might not be able to, due to conflicts in data types, etc.).

Fields to Make Editable:

• Description (description)
• Project (project)
• Tags (tags)
• Status (status)
• Urgency (urgency)
• Priority (priority)
• Due (due)
• Start (start)
• End (end)
• Entry (entry)
• Wait (wait)
• Depends (depends)
• RType (rtype)
• Recur (recur)
• Annotations (annotations)

Note: Since it is a large task, separate PRs shall be created for each field, iteratively.

[Rustix69]

@its-me-abhishek Can i work on it I will create seperate PR for each and keep this discussion updated?? Kindly assign it to me

[its-me-abhishek]

Since this is a big issue, it may require assigning it to many contributors. Please feel free to pickup any of the fields and create a PR explaining your approach in its description, will review and merge accordingly!

[Atharva1015]

Hi! I'd like to take on the Description field. I'll start working on it and will submit a PR that references this issue.

[its-me-abhishek]

hi @Atharva1015, since description is already editable, please pick some other field (any unchecked field in that checklist above)

[Ankit-69k]

Hey @its-me-abhishek ,

I reviewed the code and noticed that we’re maintaining separate states for each field. This approach increases complexity since we end up managing twice as many states as the number of fields, leading to repetitive code.

Would it be okay if I refactor this to use a single JSON state object that holds all the field values? This would simplify the logic and make the code more maintainable.

[its-me-abhishek]

single JSON state object that holds all the field values?

IMO, that would supposedly make it harder to know what command to run on the backend, separate states for each field makes it sort of easier to make requests to the backend - to run the desired TW commands

[Ankit-69k]

single JSON state object that holds all the field values?

IMO, that would supposedly make it harder to know what command to run on the backend, separate states for each field makes it sort of easier to make requests to the backend - to run the desired TW commands

As far as I can tell, handleEditTaskOnBackend is the only function being called for both the description and tags. It then invokes the editTaskOnBackend hook to update the tasks. So, I don’t see any separate API calls — it’s just that the state is being managed separately. In the end, both fields trigger the same function.

[its-me-abhishek]

you're right that handleEditTaskOnBackend is the common function being called for both description and tags.

However, we actually have two backend functions for editing tasks:

• editTask: used by the web
• modifyTask: used by the app (ref)

the short-term goal is to make as many task fields editable as possible through these two functions (starting with editTask on the web (this issue), then changing modifyTask later on for the app).

in the longer term, we plan to split these iteratively into individual field-level edits on the backend; that’ll make calls faster and payloads smaller. Once that’s stable and tested, finally we can move to a unified JSON state on frontend if and when required.

since we’ll likely need to update the frontend again when that happens, it’s better to leave the current state structure as-is for now.

[Hell1213]

hey @its-me-abhishek ,I have completed the work on the "Due" field ,and I'll create a PR shortly . Just letting you know !