depend_on_ids_one2many

Project sharing lets a customer or a contractor open a project's tasks through a portal, in an interface that looks like Odoo but is not the backend. It runs a restricted set of components, with its own views and its own idea of what a portal user may do.

Task dependencies have to appear there, because knowing what a task is waiting on is often the whole reason for looking. But the standard child list assumes backend behavior, so project sharing supplies its own renderer.

This widget is the field that uses it. Structurally it is as small as a widget gets: a child list with one component swapped. What it buys is that the dependencies render correctly in an interface that is deliberately not the backend.

Shared project access is a commercial feature before it is a technical one: it replaces status emails with a link. That only works if the shared view answers the questions a client actually has, and the first of those is usually why something has not started.

Showing dependencies read-only is the right default for that audience. A client can see that a task is waiting on two others without being able to open, reassign or reorder them, which keeps the portal informative without making it a second place where the project is managed.

The core usage

<field name="depend_on_ids"
       widget="depend_on_ids_one2many"
       nolabel="1" readonly="1"
       options="{'link': false}"/>

Read-only and non-navigable, which is the intended shape for a portal audience.

Where it belongs

# project sharing views, not the backend
project/views/project_sharing_project_task_views.xml

The renderer it uses is part of the project sharing component set.

In the backend instead

<field name="depend_on_ids" widget="many2many_tags"/>

Backend task forms use ordinary relational widgets, which have the full navigation this one deliberately does without.

There is very little code, and that is the point worth making.

The widget subclasses the child list field, replaces the list renderer with the project sharing one, and registers the result. No options, no extra props, no behavior of its own. Everything characteristic lives in the renderer, which belongs to the project sharing component set rather than to this file.

That separation is deliberate and worth recognizing when working on portal features. Project sharing is not the backend with fewer buttons; it is a separate assembly of components, and a widget written for one does not necessarily work in the other. When a portal view needs a relational list, the pattern is to wrap the portal renderer in a small field like this rather than to reuse the backend widget and patch around the differences.

The read-only treatment and the disabled link come from the view rather than the widget, which means a customization could enable them. Whether that is wise depends entirely on what your portal users should be able to reach.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The development branch is unstable and this may still change; we re-verify the page after release.

Byte-identical. The file on the development branch matches Odoo 19 exactly, which is expected for a widget whose entire content is one component substitution.