Handling of subtask confidentiality (class)

[halemmerich]

Hello,

i have found jtx Board while searching for an alternative for the seemingly no longer developed OpenTasks. That allowed to use a sort of "subtask" by using a markdown-like syntax in the tasks description. I like jtx's subtask-mechanism a lot more, but it does not seem to mesh that well with my setup.

I have a shared calendar on a SOGo instance. That allows to share a calender to another person with setting permissions for different classes. Another person I have shared my calender to is allowed to edit entries with PUBLIC class, but only view CONFIDENTIAL. Syncing and display works fine, but it seems like subtasks are always created as CONFIDENTIAL, so could not be changed by the other person. The task now has about 200 subtasks with the wrong class, which would be a bit tedious to modify, at least if done in jtx Board.

So what does the community think about these features:

• Allow bulk setting of the class for all subtasks in the detail view of a task
• Set the class of a newly created subtask to that of the parent task by default

The same probably also applies for notes.

Thanks for a great task management app!

[patrickunterwegs]

Hi @halemmerich , thank you for the discussion and sorry for the late reply!

I'm not sure if it was a typo, but basically all subtasks are created without a classification, they would then be treated like PUBLIC. Or do I have a misunderstanding here?

So basically I would see two possible changes here:
In order to overcome the problem in the first bulletpoint, I would suggest that when the classification of a task is changed and the task has subtasks, the app should ask the user if all subtasks should be updated as well. This would then also solve the bulk update. Would you agree?

Set the class of a newly created subtask to that of the parent task by default -> I agree that this should anyway be the default behavior

[halemmerich]

Thanks and no worries ;)

Interesting, in my SOGo instance all subtasks created in jtx are confidential. That may be a behaviour of the server for tasks without a class? I would have to check that with other clients. Evolution at least forces a task to have a class, the UI does not allow creating it without choosing one.

when the classification of a task is changed and the task has subtasks, the app should ask the user if all subtasks should be updated

That would solve my problem with having to use another client to fix subtasks. I think that is a minimally invasive way to give a way for changing all subtasks at once. I like the simplicity.

[patrickunterwegs]

Hey @halemmerich , fyi, first step is done and I'll provide a version with the merged pull request soon :-)
See #1628