Saltar al contenido principal
Los detalles del producto se muestran en inglés. Próximamente traducciones.
Report QWeb Element Page Visibility — A build-to-order Odoo module that lets you show or hide any QWeb report element based o — 1/1Vista previa ilustrativa

A build-to-order Odoo module that lets you show or hide any QWeb report element based on where it falls in the

printed document — first page, last page, or a specific page in the run.

ECOSIRE scopes, builds, installs, and supports it for your Odoo 17/18/19 instance.

¿Qué es Report QWeb Element Page Visibility?

A build-to-order Odoo module that lets you show or hide any QWeb report element based on where it falls in the printed document — first page, last page, or a specific page in the run. ECOSIRE scopes, builds, installs, and supports it for your Odoo 17/18/19 instance. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $999.00 USD; request a quote for a scoped proposal.

Características clave

Per-element visibility rules on QWeb report nodes: show only on first page, only on last page, on a specific nth page, or on all-but-first / all-but-last
Layered through inheritance of `web.external_layout_standard`, `_boxed`, and `_bold` templates — no Odoo core files patched, keeping the instance upgrade-safe
Declarative `t-page-visibility` data-attribute convention applied directly in report XML, evaluated against the actual paginated PDF output rather than guessed in the template loop
Correct on documents of any length — placement stays right whether an invoice renders as one page or twenty line-item pages
Works with standard reports (invoice, sale order, purchase order, delivery slip, picking) and your own custom `ir.actions.report` definitions
Configuration model exposed with `ir.model.access.csv` and record rules so only report-designer roles can edit visibility rules
Settings surfaced through XML/OWL views in the Technical menu, consistent with native Odoo UX
Compatible with the `wkhtmltopdf` / `report_pdf` rendering pipeline and respects existing paper formats and margins
Full support for Odoo 17.0, 18.0, and 19.0 on both Community and Enterprise editions
Enterprise-specific report layouts supported where present, with graceful fallback on Community
Rules provisionable and scriptable over the XML-RPC / JSON-RPC API for automated or multi-environment setup
Clean `__manifest__.py` with explicit `web` / `base` dependencies and versioned QWeb asset bundles
Header, footer, terms, and signature blocks each independently targetable so repeated legal text can be removed from interior pages
Designed to coexist with existing report customizations and third-party report layouts without template collisions

Hecho a medida, listo para ti

Sin configuración por tu cuenta: una app funcional creada, instalada y con soporte de ECOSIRE.

  1. 1

    Haces el pedido

    Empieza con un precio único de desarrollo. Definimos el alcance contigo en el arranque.

  2. 2

    Creamos e instalamos

    ECOSIRE la crea, la configura y la instala en tu Odoo.

  3. 3

    En marcha + soporte

    Sales en vivo en aproximadamente una semana laboral, con dos semanas de soporte tras la puesta en marcha. Los defectos en el código que entregamos se corrigen sin coste.

Especificaciones técnicas

Compatibilidad con Odoo
Odoo 17, Odoo 18, Odoo 19
Ediciones
Enterprise y Community
Licencia
La licencia requiere confirmación
Requisito de Python
Python 3.10+
Base de datos
PostgreSQL 12+

Sobre este producto

Every business that prints invoices, delivery slips, quotations, or purchase orders from Odoo eventually hits the same wall: the standard QWeb report renders the same header, footer, terms block, and signature area on every single page of a multi-page document. You end up with the bank details and full terms and conditions repeated on page 3 of a long invoice, or a "continued overleaf" note you cannot place only where it belongs. Odoo's report layouts and the web.external_layout templates give you a global header and footer, but out of the box there is no per-page conditional — QWeb has no native awareness of which physical page an element is landing on, because pagination happens later in the wkhtmltopdf/report_pdf rendering step, not in the template loop. Teams work around this with brittle CSS page-break hacks that break the moment a line item count changes.

Report QWeb Element Page Visibility is the module we build to give you real, declarative control over where report elements appear. We add a small extension to the QWeb reporting stack so any element in your report templates can carry a visibility rule — show only on the first page, only on the last page, only on a specific page number, or on every page except the first or last. Technically this is delivered through a targeted report.layout/ir.actions.report extension plus a lightweight rendering pass that annotates the generated PDF pages, driven by data attributes you place on the QWeb nodes (for example a t-page-visibility="first|last|nth" convention). Because the logic keys off the actual paginated output rather than guessing in the template, it stays correct whether a document renders as one page or twenty. We wire it cleanly into your existing web.external_layout_standard/_boxed/_bold templates or your custom report views, so your bank-details block lands only on the last page, your signature line prints only where it should, and repeated legal text disappears from the interior pages.

Under the hood we keep everything on standard Odoo foundations: a proper __manifest__.py declaring the web and base dependencies and the QWeb template assets, any configuration surfaced through ir.model fields with ir.model.access.csv entries and record rules so only report designers can edit the rules, and views built in XML/OWL that fit the native Settings and Technical menus. No core files are patched — the behavior is layered through inheritance so your Odoo stays upgrade-safe. The module is built and tested against Odoo 17.0, 18.0, and 19.0, works on both Community and Enterprise (Enterprise's additional report layouts are supported where present), and exposes its configuration over the standard XML-RPC/JSON-RPC API so it can be provisioned or scripted alongside the rest of your deployment.

Because this is a build-to-order engagement, delivery starts with a short scoping call where we confirm which reports need per-page control, your exact page-placement rules, and your target Odoo version and edition. There is no instant download — we build the module to your requirements, test it on a staging copy of your database, run UAT with your team, and then install to production with a rollback plan. Typical delivery is one working week from confirmed scope. Pricing starts from $999 (indicative, single-company base scope); additional report templates, deep Enterprise layout customization, multi-company placement rules, or bespoke pagination logic beyond the standard first/last/nth cases increase the quoted scope. You receive a firm fixed quote after the scoping call — the from-price is a starting indication, not a final figure.

lo que obtienes

  • Installable Odoo module source code, built for your target version (17.0, 18.0, or 19.0) and edition
  • Installation and configuration on your environment, including wiring into your existing report layouts
  • Technical documentation: module architecture, the `t-page-visibility` convention, and how rules are evaluated
  • End-user guide plus a live training session for your report designers and admins
  • UAT on a staging copy of your database with a documented rollback plan before production install
  • Post-go-live support window for defect fixes and configuration questions
  • Git repository handover with full commit history and tagged release
  • Test report templates demonstrating first-page, last-page, and nth-page placement against your real documents

¿Para quién es esto?

Odoo Report Designer / Functional Consultant

Owns the look of printed invoices and orders and is tired of CSS page-break hacks. Needs a declarative, maintainable way to place blocks per page that survives line-item count changes and Odoo upgrades.

Finance / Accounts Operations Lead

Wants bank details, payment terms, and totals to appear only on the last page of long invoices — and repeated legal text gone from interior pages — so customer-facing documents look professional and unambiguous.

Odoo Technical Administrator / Developer

Runs the instance and cares about upgrade safety. Wants the behavior layered through inheritance with proper `ir.model.access.csv`, record rules, and API-scriptable configuration, not a patched core.

Compliance / Legal Operations Manager

Needs terms, disclaimers, and signature lines to print in a specific, controlled position on the correct page for contractual and audit purposes, consistently across every document type.

Cómo se compara Report QWeb Element Page Visibility

CriterioECOSIREConstrucción personalizadaCompetidorNativo de Odoo
Per-page element visibility (first / last / nth)Built to your exact rules across chosen reportsPossible but you design and maintain the logic yourselfFixed feature set, may not cover nth-page or your layoutsNo native per-page conditional in QWeb
Fit to your specific reportsScoped to your documents on a discovery callFully tailored if you have the in-house dev timeGeneric; you adapt your reports to itGlobal header/footer only, same on every page
Upgrade safety (17/18/19)Inheritance-based, no core patches, version-testedDepends on your team's disciplineVaries by vendor; upgrade timing not in your controlSafe but lacks the capability entirely
Delivery modelBuilt, tested on staging, installed with rollback planYou build, test, and deploy yourselfInstant download, you self-install and debugAlready present but insufficient
Time to working solutionone working week from confirmed scopeWeeks to months of internal dev effortMinutes to install, then your own troubleshootingImmediate but requires fragile CSS workarounds
Support and accountabilityPost-go-live support window + Git handoverRests entirely with your teamTicket queue, best-effort, no context on your setupCommunity forums only
CostFrom $999 indicative; fixed quote after scopingHigh internal engineering cost and opportunity costLow sticker price, hidden integration costFree but does not solve the problem
Security and permissionsir.model.access.csv + record rules for designer rolesYou implement access control yourselfDepends on vendor implementationN/A — no configurable feature

Preguntas frecuentes sobre Report QWeb Element Page Visibility

Is this an existing app I can download and install right now?

No. This is a build-to-order module. ECOSIRE builds it to your specific report and page-placement requirements, tests it on a staging copy of your database, and installs it for you. There is no instant download.

How long does delivery take?

Typical delivery is one working week from confirmed scope. The timeline starts once we have agreed which reports need per-page control, your exact placement rules, and your target Odoo version and edition on the scoping call.

How does pricing and scoping work?

Pricing starts from $999 as an indicative, single-company base-scope figure. Drivers such as additional report templates, deep Enterprise layout work, multi-company rules, or bespoke pagination logic increase the quoted scope. After the scoping call you receive a firm fixed quote — the from-price is a starting indication, not the final figure.

Which Odoo versions and editions do you support?

We build and test against Odoo 17.0, 18.0, and 19.0, on both Community and Enterprise. Enterprise-specific report layouts are supported where present, with graceful fallback on Community.

What about support and future updates?

Every build includes a post-go-live support window for defect fixes and configuration questions, plus a Git repository handover so your team has the full source. Version upgrades or new report rules beyond the support window are quoted as a separate small engagement.

Will this break when I upgrade Odoo?

The module layers its behavior through inheritance of the standard report layouts rather than patching core files, which keeps your instance upgrade-safe. When you move to a new Odoo major version we verify and, if needed, adjust the module as part of a migration engagement.

Can it target our existing custom reports, not just standard ones?

Yes. It works with standard Odoo reports and with your own custom `ir.actions.report` definitions and QWeb templates. During scoping we confirm exactly which documents and which elements need per-page visibility rules.

Solicitar presupuesto

Report QWeb Element Page Visibility

A build-to-order Odoo module that lets you show or hide any QWeb report element based on where it falls in the printed document — first page, last page, or a specific page in the run. ECOSIRE scopes, builds, installs, and supports it for your Odoo 17/18/19 instance.

  • Per-element visibility rules on QWeb report nodes: show only on first page, only on last page, on a specific nth page, or on all-but-first / all-but-last
  • Layered through inheritance of `web.external_layout_standard`, `_boxed`, and `_bold` templates — no Odoo core files patched, keeping the instance upgrade-safe
  • Declarative `t-page-visibility` data-attribute convention applied directly in report XML, evaluated against the actual paginated PDF output rather than guessed in the template loop
  • Correct on documents of any length — placement stays right whether an invoice renders as one page or twenty line-item pages

Solicitar presupuesto

Cuéntanos tus necesidades de Report QWeb Element Page Visibility y te enviaremos precios, opciones de licencia y una propuesta a medida, normalmente en un día hábil.

Sin pago ahora. Esto envía una solicitud de presupuesto a nuestro equipo; te responderemos por correo con precios y próximos pasos.