⚠️ Potential issue |🟠 Major

Existing root pages retain duplicatesort_order values.

This loop copiesPage.sort_order toProjectPage.sort_order only for child pages (parent_id__isnull=False). Existing root pages (withparent_id=None) will all have the default65535 in theirProjectPage records.

Consider also assigning uniquesort_order values toProjectPage entries for root pages:

# After updating child pages, handle root pages similarlyroot_project_pages=ProjectPage.objects.filter(page__parent_id__isnull=True).select_related("page")# Assign unique sort_order per project...

⚠️ Potential issue |🔴 Critical

Syntax error:list[Any] is a type hint, not callable.

list[Any](...) will raise aTypeError at runtime. Uselist(...) to convert the queryset to a list:

-        pages = list[Any](+        pages = list(             Page.objects             .filter(workspace_id=workspace_id, sort_order=DEFAULT)             .only("id", "sort_order")         )

Also, theAny import on line 3 becomes unused after this fix.

In apps/api/plane/db/migrations/0113_auto_20251215_0934.py around lines 52 to56, the code uses the type hint `list[Any](...)` which is invalid at runtime;replace `list[Any](Page.objects.filter(...).only(...))` with a plain`list(Page.objects.filter(...).only(...))` to materialize the queryset, andremove the now-unused `Any` import from the top of the file.

⚠️ Potential issue |🟡 Minor

Reverse migration doesn't restorePage.sort_order changes.

The forward migration modifies bothProjectPage.sort_order (lines 20-31) andPage.sort_order (lines 61-65), but the reverse only resetsProjectPage.sort_order. If the migration is rolled back,Page.sort_order values will remain modified.

If reversibility is important, consider either:

1. Storing original values and restoring them in reverse
2. Documenting thatPage.sort_order changes are permanent

In apps/api/plane/db/migrations/0113_auto_20251215_0934.py around lines 68-71,the reverse_set_page_sort_order currently only resets ProjectPage.sort_order anddoes not undo the changes made to Page.sort_order in the forward migration;update the reverse function to also restore Page.sort_order (either by settingit back to the same DEFAULT_SORT_ORDER constant used for ProjectPage or, iforiginal values were captured, restore those original values) so the rollbackfully reverts both models, or explicitly document in the migration header thatPage.sort_order changes are irreversible if you choose not to implementrestoration.

Invalid type annotation syntax. The expression 'listAny' attempts to call 'list[Any]' as a function, but this is not valid Python. This should be either a list comprehension or use the list() constructor without the type parameter. The correct syntax would be 'pages = list(Page.objects.filter(...))' or simply assign the queryset directly if you need to iterate over it multiple times.

The documentation states this method sets sort_order "when the associated page has no parent in the workspace," but the implementation doesn't check whether the page has a parent. The method always sets the sort_order for any new ProjectPage. Consider either updating the documentation to match the implementation or adding a check for 'self.page.parent_id is None' if the behavior should only apply to root pages.

Inconsistency between migration logic and model behavior. The migration (lines 20-31) copies sort_order from Page to ProjectPage only for pages WITH a parent (parent_id__isnull=False), but the model's save() method sets sort_order for ALL new ProjectPages regardless of parent status. This creates different behavior for existing vs new records. The logic should be aligned: either both should handle all pages, or both should only handle root/child pages consistently.

The queryset is ordering by "-is_favorite" and "-created_at" but the newly added sort_order field is not being used for ordering. Since the PR description states this is to "add sorting of page in project level pages," you should update the order_by clause to include sort_order. For example: .order_by("-is_favorite", "sort_order", "-created_at") to order by favorites first, then by sort order, then by creation date.

The method name '_set_sort_for_root_page' implies it only applies to root pages (pages without a parent), but it's actually called for all new ProjectPage instances. Consider renaming to '_set_sort_order' or '_set_initial_sort_order' to better reflect its actual behavior, which sets sort_order for any new ProjectPage regardless of whether the associated page has a parent.

Calling .iterator() on a values_list QuerySet is unnecessary and potentially problematic. The values_list() already returns a QuerySet, and calling iterator() on line 43 before iterating creates an additional layer. Since workspace_ids is already a QuerySet that will be lazily evaluated, you can directly iterate over it with 'for workspace_id in workspace_ids:'. The chunk_size parameter on iterator() is also redundant here since you're iterating over workspace IDs (which should be a small set), not large model instances.

There are two order_by() calls in the queryset chain - one at line 100 and another at line 111. In Django's QuerySet chaining, the second order_by() call will completely override the first one. This means the order_by clause at line 100 that uses the request parameter is ineffective. You should either remove line 100 or combine both ordering strategies into a single order_by() call.