Hi @lpb,
Currently, because we have not begun the deprecation, “section” tasks (not just subtasks) indicate that they are “sections” through their resource_subtype. However, going forward, they will eventually indicate resource_subtype: "default_task" as mentioned in my earlier post:
Task-sections will no longer have special meaning. Currently, a task-section’s
resource_subtypeattribute in the API will read"section", but they will eventually become standard tasks withresource_subtype: "default_task".
You can use the resource_subtype to determine if a task is a “section” for the time being, but be aware that this will be deprecated over the next few months as task-sections are replaced with proper column-sections.
After the migration, the API will no longer distinguish “section” subtasks from “plain” subtasks because doing so would lead to inconsistent data. Sections in subtasks are purely visual markers, and there’s nothing in their structure that makes them different from regular tasks—they can still be assigned, given due dates, commented on, etc. Although this is difficult to do in the new UI, it’s not impossible, and it’s not forbidden in our data model.
Importantly, subtask sections can be multi-homed like normal tasks. After we have completed the migration, if you multi-home a subtask “section” into a normal project, it will be a plain task and look like all the tasks around it—it will not be a real section, and will not look like a section. The data you fetch from the API should not be different depending on how you access it, so fetching that task through GET /tasks/<id>, GET /tasks/<parent-id>/subtasks, and GET /projects/<project-id>/tasks must all return the exact same data for the subtask “section.” The only response that can be consistent with our data model and across all views of that data is to report that resource_subtype: "default_task", even if the task is styled as a section when you view it as a subtask in the task pane.
Regarding the activation date of the API migration: the API portion of this work is progressing independently of the web app work. The dates provided from the API team will reflect only the changes in the API, while the changes you see in the web app may happen earlier or later.