Sections are dead! Long live sections!

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.

Your issue might be that the section a task belongs to needs to be given in a membership attribute. See Build an app with Asana for details.

Exactly what @Bastien_Siebman said! Check out the tasks documentation page he referenced - you’ll see there’s no section property on a task object that you can access directly. When creating a new task, use memberships as Bastien pointed out. When you want to modify an existing task’s section, use the addProject and/or removeProject endpoints (documented on that same page).

1 Like

It’s my first time using board layout and adding tasks to sections. It turns out this is how it needs to be done using the Python client library:

Tasks have to to be first added to a project as such:

new_task = client.tasks.create(task)

And then move them to the right section as such:

client.tasks.add_project(new_task['gid'],
                                              {'project': '5678',
                                                'section': '67891'}
                                          )

Would have been more convenient if it was possible to do it all in one call. Thanks for all your prompt responses.

Hi all, I have some new updates to share about the upcoming section changes!

Rollout and Timeline

For new customers—50% new customers signing up for Asana are now being automatically put into the new data model where all projects have real columns and projects can be viewed both as a board and a list.

For existing customers—beginning in mid- to late-June, existing workspaces and organizations will begin migrating into the new data model. During this period, entire workspaces will be migrated as a whole single unit. Projects in the workspace will be locked as Asana rebuilds the project with the new data model. The vast majority of projects will take between 30 seconds and 5 minutes to migrate, after which they will unlock for use again.

Once the migration is steadily underway we will provide an update on when we expect the migration to finish for all workspaces, and when we will be permanently enabling the new_sections deprecation.

Iteration order on boards has been corrected

We have finished building the new indices and queries that allow GET /projects/<project-gid>/tasks to return tasks in the “correct” order that they would be seen in the project. As of this morning, you should see tasks from the first column top-to-bottom, followed by the second column top-to-bottom, and so on.

We are deprecating (half of) one story type

Asana has “section changed” stories (resource_subtype: "section_changed") where the “section” here sometimes refers to old task-sections/separators. The API is deprecating these stories because they are no longer accurate—their old_section and new_section fields don’t point to real column-sections. If you have enabled the new_sections deprecation, you will now see resource_subtype: "deprecated" for these stories and they will not have the extra fields on them. “Section changed” stories that do refer to real column-sections will not be affected.

As always, reply in this thread if you have additional questions, and we’ll update this post as necessary.

@Pradyumna_Dhakal, it is indeed possible to put a task in a particular section in the same request where the task is created. Refer to this other post for an example.

Hi Joe,

During this process, will webhooks be firing for these projects? I ask because if they will be, and if some migration change triggers Flowsana to want to make a change to a task in the project (I’m not sure if any potential migration change might trigger a Flowsana rule, for example, but I’m covering my bases here), then I presume Flowsana’s attempted update will fail because the project is locked? And if so, what error should we expect to see returned?

Wow I did not expect the change to be rolled out without a warning, I must have missed some information… @Joe_Trollo can we have access to an Org to test our code? Or should I just created accounts until I have access to the feature :sweat_smile:?

OK, I see that you had already answered the second part of my question. So the only remaining question is, will webhooks fire for changes that the migration makes?

As a corollary to this question from Bastien…

I store SectionIDs and thus am going to need to use the GET /tasks/<task-id>/sectionsMigratedTo endpoint to convert existing task-section IDs to their new equivalent (and of course also have to deal with the fact that one task-section may spawn multiple new-sections).

I’m still trying to figure out how/when I’m going to have to trigger this conversion on a customer’s data - that’s my problem - but in addition, it’s going to be extra tough if there’s no way to test my conversion code until the first of my customers have been converted and then that means I’m having to test my new code on live customer data :worried:. As Bastien said, is there a way to get access to some test converted data so we can test conversion code like I’ve described? Or if there is not, then as an alternative, could you perhaps have the conversion team convert our own developer workspaces now (or as soon as its available) if we request it, before they start converting other user workspaces, to give us a little time to test conversion code? I’d be happy to be a guinea pig and have my own main workspace converted first.