メインコンテンツにスキップ
商品詳細は英語で表示されます。翻訳は近日公開予定です。
Hide Powered By — A build-to-order Odoo module that removes the default vendor branding from your login, signup, and password — 1/1イメージプレビュー

A build-to-order Odoo module that removes the default vendor branding from your login,

signup, and password-reset screens.

ECOSIRE builds it to your scope, installs it, and supports it — this is a made-to-order service, not an instant download.

Hide Powered Byとは?

A build-to-order Odoo module that removes the default vendor branding from your login, signup, and password-reset screens. ECOSIRE builds it to your scope, installs it, and supports it — this is a made-to-order service, not an instant download. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $999.00 USD; request a quote for a scoped proposal.

主な機能

Server-side removal of the framework branding credit from the `web.login` QWeb template so it never renders in the served HTML, not just CSS-hidden
Inheriting view overrides using `xpath` with `position="replace"` or guarded `t-if`, leaving Odoo core `web` source untouched and upgrade-safe
Coverage of signup and password-reset screens via `auth_signup` template inheritance (`web.signup`, `web.reset_password`) when public signup is enabled
Portal footer branding suppression for external/portal users, matched to your `portal` layout
Behaviour gated by an `ir.config_parameter` flag so the change is explicit, toggleable, and auditable in the database
Defensive compiled CSS asset bundled through the module as a second layer against theme-injected branding
`__manifest__.py` declares correct `web`/`auth_signup` dependencies and asset bundles so installation is a clean addon deploy
Community vs Enterprise parity handling, since the login `web.login_layout` structure differs between editions
Compatibility with your existing custom login logo, favicon, and background theme — the module coexists rather than overriding your branding
Correct behaviour behind reverse proxies and with a configured `web.base.url`, verified on the actual served page
Multi-company and multi-website aware branding rules where your database runs several brands (scoped add-on)
Built and tested for Odoo 17.0, 18.0, and 19.0 with the version-specific template differences accounted for
No new access rules or record rules required — a configuration-only feature that does not widen `ir.model.access.csv` or data visibility
Clean uninstall path that removes the override and restores default rendering without residual config parameters

受注生産、すべておまかせ

自分での設定は不要 — ECOSIRE が構築・インストール・サポートする実働アプリです。

  1. 1

    ご注文

    一回限りの構築料金から始めます。キックオフで一緒に範囲を決めます。

  2. 2

    構築とインストール

    ECOSIRE がお客様の Odoo 上で構築・設定・インストールします。

  3. 3

    本番稼働 + サポート

    約1週間(営業日ベース)で稼働し、本番稼働後2週間のサポートが付きます。納品したコードの不具合は無償で修正します。

技術仕様

Odoo互換性
Odoo 17, Odoo 18, Odoo 19
エディション
Enterprise&Community
ライセンス
ライセンスの確認が必要です
Python要件
Python 3.10+
データベース
PostgreSQL 12+

この製品について

Your Odoo login screen is the first thing employees, clients, and portal users see every day — and out of the box it carries a framework branding credit beneath the authentication card. For a company presenting Odoo as its own internal platform or a white-labelled client portal, that leftover credit undercuts the brand you have spent money building everywhere else. Odoo core lets you swap the header logo and set a company favicon, but the web-login QWeb template (web.login, web.login_layout, and the signup/reset variants) still renders the branding block server-side, and there is no Settings toggle to remove it. You are left either editing core templates in place — which every upgrade silently overwrites — or leaving the credit where it sits.

Hide Powered By is a purpose-built module that cleanly suppresses that branding on every authentication surface without touching Odoo core. Technically, we ship a small addon whose __manifest__.py depends on web (and on auth_signup when your database exposes public signup), and we override the relevant QWeb templates with an inheriting view — an xpath targeting the branding node with position="replace", or a guarded t-if — so the credit no longer renders in the served HTML rather than being merely hidden by CSS that a user can defeat through the browser inspector. We wire the behaviour to a flag stored in ir.config_parameter so the change is explicit and auditable, and we include a defensive stylesheet asset as a second layer. Because the override lives in its own addon, it survives module and minor-version upgrades and can be toggled or removed cleanly.

The build covers every place the branding appears in your flows: the standard /web/login, the /web/signup and /web/reset_password screens, the portal (portal) footer branding for external users, and the backend "about" surface where relevant to your scope. We keep it framework-clean — no monkey-patching of core Python, no edits to web source — so security stays intact: no new ir.model.access.csv rows or record rules are required beyond what a configuration-only feature needs, and nothing widens data access. We validate the result against your actual login theme, custom logo, and any reverse-proxy or web.base.url setup so the served page is genuinely clean for both authenticated staff and public portal visitors, and we confirm parity across Community and Enterprise since the login layout differs subtly between the two.

Delivery is build-to-order: after a short scoping call we confirm exactly which authentication and portal surfaces are in scope and your target Odoo series, then build against a copy of your theme, test on a staging database, and hand over installable source plus a rollback plan. Typical delivery is one working week from confirmed scope. Pricing starts from $999 (indicative, single-company base scope); additional surfaces, multi-company or multi-website branding rules, deep custom-theme integration, and localization depth increase the quoted scope. You receive a fixed quote after the scoping call — never a surprise on the invoice.

得られるもの

  • Installable module source code for your confirmed Odoo version (17.0, 18.0, or 19.0), built against your theme
  • Installation and configuration on your staging environment, then production, including the `ir.config_parameter` flag setup
  • Technical documentation covering the manifest, template overrides, and how the config flag controls behaviour
  • Short admin user guide plus a live handover/training session for your team
  • UAT on a staging database with a documented rollback plan before any production change
  • Post-go-live support window for defect fixes and version-specific adjustments
  • Git repository handover with full commit history and tagged release
  • Compatibility notes for future Odoo minor-version upgrades and known theme interactions

これは誰のためのものですか

IT / ERP Administrator

Owns the Odoo instance and needs the login and portal screens to present the company brand cleanly, without editing core templates that upgrades would overwrite. Wants an upgrade-safe addon and a clean uninstall path.

Agency / White-Label Implementation Partner

Delivers Odoo to end clients as a branded platform and cannot have a third-party framework credit on the client's login page. Needs a repeatable, source-delivered module they can deploy per client engagement.

Brand / Marketing Lead

Responsible for consistent brand presentation across every customer touchpoint, including the client portal login. Wants the authentication and portal surfaces to look wholly first-party.

Managed-Hosting / SaaS Operator

Runs multi-company or multi-website Odoo for several brands and needs branding rules that resolve correctly per company/website, applied consistently across tenants.

Hide Powered By の比較方法

基準エコシエールカスタムビルド競合他社Odoo 標準機能
Upgrade safetyOwn addon overriding QWeb — survives upgradesDepends on the developer; often edits coreUsually addon-based but genericNo option; editing core is overwritten on upgrade
Removal methodServer-side template override, not renderableVaries — may be CSS-only and defeatableOften CSS-hide; visible via inspectorNo mechanism to remove
Surface coverageLogin, signup, reset, portal — to your scopeWhatever is specified and paid forTypically login onlyNone
Edition parityBuilt and verified for Community and EnterpriseOnly what is testedMay target one editionSame gap on both editions
Fit to your themeValidated against your logo, theme, hostingPossible with extra effortGeneric; may clash with custom themesNot applicable
Support & updatesPost-go-live window + version rebuildsRetainer or ad-hocVendor support queue, if anyNone
Source & handoverFull source + git repo handoverUsually yesOften encrypted/obfuscatedNot applicable
Delivery modelBuild-to-order, one working week, fixed quoteProject timeline, variableInstant download, self-installIncluded but non-functional for this need

Hide Powered By に関するよくある質問

How long does delivery take?

This is a build-to-order module. After a scoping call to confirm which authentication and portal surfaces are in scope and your target Odoo series, typical delivery is one working week from confirmed scope. We build against a copy of your theme, test on staging, and schedule the production install with you.

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

No. We build, install, and support it for your specific instance and Odoo version. There is no instant download — the value is a clean, upgrade-safe implementation validated against your actual login theme, editions, and hosting setup, with a rollback plan and handover.

How does pricing and scoping work?

Pricing starts from $999 (indicative, single-company base scope). The final number depends on how many surfaces are involved (login only versus login, signup, reset, and portal), multi-company or multi-website branding rules, custom-theme depth, and localization. You get a fixed quote after the scoping call — never a surprise on the invoice.

Will it survive Odoo upgrades and updates?

Yes. Because the change lives in its own addon that inherits and overrides QWeb templates rather than editing Odoo core `web` source, it survives module and minor-version upgrades. Major-version jumps (e.g. 18.0 to 19.0) may need a small adjustment for template differences, which the post-go-live support window and our version-specific builds cover.

Does removing the branding affect security or data access?

No. It is a configuration and presentation change only. It adds no `ir.model.access.csv` rows or record rules, does not monkey-patch core Python, and does not widen any data visibility. The served login page is simply cleaner; authentication logic is untouched.

Does it work on both Odoo Community and Enterprise?

Yes. The login layout (`web.login_layout`) differs subtly between editions, so we build and verify against whichever you run. If you have both, we account for the differences in scope.

What exactly do I receive at handover?

Installable module source for your Odoo version, installation and configuration on staging then production, technical docs, a short admin guide plus a training session, UAT with a rollback plan, a post-go-live support window, and the git repository with full history.

見積もりを依頼

Hide Powered By

A build-to-order Odoo module that removes the default vendor branding from your login, signup, and password-reset screens. ECOSIRE builds it to your scope, installs it, and supports it — this is a made-to-order service, not an instant download.

  • Server-side removal of the framework branding credit from the `web.login` QWeb template so it never renders in the served HTML, not just CSS-hidden
  • Inheriting view overrides using `xpath` with `position="replace"` or guarded `t-if`, leaving Odoo core `web` source untouched and upgrade-safe
  • Coverage of signup and password-reset screens via `auth_signup` template inheritance (`web.signup`, `web.reset_password`) when public signup is enabled
  • Portal footer branding suppression for external/portal users, matched to your `portal` layout

見積もりを依頼

Hide Powered By のご要望をお知らせください。価格、ライセンスの選択肢、貴社に合わせたご提案を、通常1営業日以内にお送りします。

今すぐのお支払いはありません。これはチームへの見積もり依頼を送信します。価格と次のステップをメールでご案内します。