Sections are dead! Long live sections!

Hi @Joe_Trollo ,

Not sure if you answered already or not. When do you plan to disable (in the API) the ability to create a section just by using the colon? I just need to make sure I fix my code before you do.

Thanks

Hi @Bastien_Siebman, there is no way to create a section in the API with a task whose name ends in a colon. It is only possible to create separators. When creating new tasks (i.e., POST /tasks) there are two cases:

  • You are not sending a change header, or are sending the Asana-Disable: new_sections header. In this case, when you create a task that ends in a colon, it will be rendered as a separator in unmigrated projects and will have the is_rendered_as_separator field implicitly set to true. It will not be rendered as a separator in migrated projects or current boards projects. This behavior will naturally be deprecated as more and more projects are migrated.
  • You are sending an Asana-Enable: new_sections header. In this case, tasks are never created as separators based on the name. Instead, you will need to set the is_rendered_as_separator field explicitly. Tasks will only be rendered as separators in unmigrated projects (and lists of subtasks and users’s My Tasks).
1 Like

Is it correct to say that all the new projects (created from now on) are “migrated projects” from the start?

Does that mean any project created with the API will be displayed as board by default and user will have to manually set the view to list? Will we be able to choose the list layout by default at creation?

Hi @Bastien_Siebman,

No, no projects are migrated yet. The UI to choose to migrate a project has not been rolled out to us yet.

It seems like, if you enable the deprecation, you can only create a Board project with the API and that’s what the user will see, but @Joe_Trollo should answer this one for sure! If so, then I think, Bastien, that you might want to test with the deprecation enabled, but not enable in production early as a result of this.

Hope that helps,

Larry

1 Like

This is correct. So far, nothing has changed about how the vast majority of projects are structured or created in Asana, with the exception of a few beta tests. We will eventually roll out the ability for users to migrate their own projects, and sometime after that we will enforce that all new projects follow the new data model.

The default view for a project created through the API will be the same as the default view as projects created in the web app. I am almost certain that once the project data models are unified, “list view” will be the default for any new project, but this is a product decision in the hands of another team.

2 Likes

That is very clear. A big thank to you and to @lpb who helped me sort things out.

3 Likes

@Joe_Trollo We are pulling a list of task in hierarchical order Sections-Task-Subtasks. The first round at the pull shows sections as just normal tasks. I am not a developer but would like to know if changes have been made yet that allow the identification enough for the list to identify the section so the list would look like

Section
Parent Task
Subtask

Thanks

From my latest discussions with @lpb, what I understood is that when you enable the new section model, you can’t really create sections (yet). You can only create sections in My Tasks and inside subtasks, but not in a regular project, because project are not migrated yet…

In the near future, a list layout project will just behave as a current board layout. So just prepare the code to create board layouts (sections are columns) and wait for the API to be able to create a "migrated project’… I’ll let @Joe_Trollo confirm or not!

1 Like

Yes, I believe. Except…a minor change:

1 Like

One additional change, I believe:

You should still be able to create sections in a board project because those aren’t changing from the current model.

1 Like

Hi @James_Carl, have you enabled the new_sections header for this deprecation? If you have, then to see the sections in a project you must use either GET /projects/project-id/sections or GET /projects/project-id/tasks?opt_fields=memberships.(section|project). Note that, with the deprecation enabled, current list-view projects have no sections in them and you will see only a flat list of tasks.

If you are in a current list-view project and wish to see separators, then you should look at the is_rendered_as_separator field on the tasks to indicate the “hierarchy” in the flat list of tasks.

2 Likes

How will behave a task without a section from a list layout project, once displayed as board? I tried to create a task in a board without associating a column, looks like it does not create the task at all… Maybe I missed something from the documentation.

@Bastien_Siebman, all tasks will end up in some column. Tasks at the top of the project in “no section” will be put into a newly created column as part of the migration.

Thanks a lot. I just tried, and if I put them in a column name " " (space), the column ends up being named “Untitled Column”. Works for me :+1:

@Joe_Trollo do you have some equivalent to know if the entire org has been migrated or not? Because if I understand well, and if you don’t have this flag, then we would have to create the project with the API, then query the project to get the migration flag, to know which code to use to create the project correctly.

1 Like

There is no flag indicating whether an entire workspace has been migrated. You can use opt_fields=section_migration_status when you create the project to see whether it’s using the old data model or the new data model. The migration process is happening separately from the roll-out of changes to project creation (first, we make all new projects be in the new data model, then we migrate old projects) so the workspace-level flag about the migration wouldn’t actually provide the information you need when creating new projects.

In my case it would be a flag indicating whether or not a new project would have the new model or not. Thanks for the tip :+1:

So I’ve been making code changes (perhaps a little late in the game) to account for this upcoming API change. I have two sections on a board layout project and trying to add a few tasks to each section using the Python client library. No matter how many times I try, it adds tasks only to the first section, despite the data I sent clearly shows different section for one of the tasks.

Not sure if this behavior is related to the change but I thought it appropriate to post it here as I’m making adjustments and testing for this change. Any help would be appreciated

1 Like

It’s only list layout projects that are changing, boards already have sections implemented in the “correct” way. So I don’t think it would be related to this architecture change.

Can you post your code so we can look at exactly what you’re doing?

1 Like

Conceptually, this is what I am doing using the Python client library. I’ve mocked the IDs for privacy purposes.

task_a = {‘workspace’: ‘12345’, ‘projects’: [‘5678’], ‘section’: ‘67890’, ‘name’: ‘task_a’}
task_b = {‘workspace’: ‘12345’, ‘projects’: [‘5678’], ‘section’: ‘67890’, ‘name’: ‘task_b’}
task_c = {‘workspace’: ‘12345’, ‘projects’: [‘5678’], ‘section’: ‘67890’, ‘name’: ‘task_c’}

task_d = {‘workspace’: ‘12345’, ‘projects’: [‘5678’], ‘section’: ‘67891’, ‘name’: ‘task_d’}

tasks = [task_a, task_b, task_c, task_d]

for task in tasks:
client.tasks.create(task)

I’d expect task_d to be added to section with GID ‘67891’ but all 4 tasks are being added to section with GID ‘67890’

It may be that I’m making a blunder but can’t figure out how.