tour_start_widget

Odoo ships an interactive tour engine: sequences of pointer steps that walk a user through a flow, used for onboarding and, in automated mode, for testing. Since Odoo 18, tours can live in the database, including custom ones captured with the tour recorder, and they get a management screen under Settings, Technical, Tours when developer mode is on. This widget is that screen's play control.

It is technically a char field widget placed on the tour's name, but it never renders the name. The template replaces the value with two buttons. Onboarding calls startTour in manual mode: the pointer appears and waits for the user to perform each step, starting at the tour's configured URL. Testing runs the same tour in auto mode, the engine performing every step itself with a 250 millisecond pointer delay so a human can watch it work.

Both runs are built from the record's own data: the tour name, its starting URL, whether it is a database-defined custom tour, that is the fromDB flag, and the rainbow-man congratulations message shown at the end, an HTML field defaulting to Good job! You went through all steps of this tour.

Two audiences meet on this screen. For operations and training teams, the Tours list plus the recorder is a no-code way to build guided walkthroughs of your own processes: record the flow once, and every new hire can replay it against the real UI with the Onboarding button. It will not replace documentation, but for how do I create a credit note type questions it beats a PDF by a wide margin.

For teams maintaining customizations, the Testing button is a cheap smoke test. An automated tour that walks your quotation flow and ends in the rainbow man is a regression check anyone can run after an upgrade, no test framework knowledge required. We record exactly such tours as part of custom Odoo delivery so clients can self-verify core flows after every update.

The practical caveat: tours run against the live database. An automated tour that creates a quotation really creates one. Run Testing on a staging copy, or make the tour clean up after itself.

How core uses it (tour form header)

<header>
    <field name="name" widget="tour_start_widget"/>
</header>

In the Tours list, link-styled

<list js_class="tour_list" create="0" edit="0">
    <field name="name"/>
    <field name="url"/>
    <field name="custom"/>
    <field name="rainbow_man_message" column_invisible="1"/> <!-- Invisible to get the data in JS -->
    <field name="name" widget="tour_start_widget" options="{'link': true}" string=""/>
</list>

Core's own comment on the invisible column is the documentation: the widget reads rainbow_man_message, url and custom from the record without declaring dependencies, so the view must load them. The list also demonstrates the trick of placing name twice, once as text, once as the buttons.

The two modes differ by three parameters. Both buttons call tour_service.startTour with the tour name, the starting URL and fromDB: custom. Onboarding passes mode: "manual"; Testing passes mode: "auto" plus showPointerDuration: 250 so each step's pointer flashes visibly. Odoo 18's Testing also sent stepDelay: 500, a half-second pause between steps, dropped in 19, so automated runs are noticeably faster after the upgrade.

fromDB decides where steps come from. Code-defined tours are looked up in the client-side registry; database tours, the recorder's output, are fetched from the server. The widget wires that switch to the record's custom boolean, which is why the column sits in the list view.

The link option's whole implementation is a class swap. With link truthy the buttons render btn-link py-0 instead of btn-primary. It is undocumented, never declared in supportedOptions, and exists solely so the list view can show quiet text-style actions while the form header gets solid buttons.

Button captions are hardcoded. The template says Onboarding and Testing, translatable but not configurable. Renaming them means inheriting web_tour.TourStartWidget.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The following reads the public development branch, which is unstable until feature freeze; this page is re-verified against the shipped release.

The link option is deleted, replaced by view-type detection. On the branch, extractProps ignores options entirely and returns link: viewType === "list": list views automatically get the quiet link styling, forms get solid buttons, and the Tours list drops its options="{'link': true}" accordingly. Custom views passing the option will not break, the key is simply ignored, but forcing link styling on a form, or solid buttons in a list, stops being possible without inheriting the template.

Everything else holds. Same two buttons, same modes, same record fields, with the prop plumbing migrated to the new typed-props API. A tour-based smoke suite should survive the upgrade untouched; re-record any tour whose underlying flow your Odoo 20 migration changes.