| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
eCommerce (website_sale)
• Website (website) • Invoicing (account) • Discuss (mail) |
| Lines of code | 629 |
| Technical Name |
aglow_multi_delivery_cart |
| License | OPL-1 |
| Website | http://aglow.dev |
| Versions | 18.0 19.0 |
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
eCommerce (website_sale)
• Website (website) • Invoicing (account) • Discuss (mail) |
| Lines of code | 629 |
| Technical Name |
aglow_multi_delivery_cart |
| License | OPL-1 |
| Website | http://aglow.dev |
| Versions | 18.0 19.0 |
M/01 — Alpenglow module
One portal user, two or more delivery locations — an independent draft cart for each, plus a dropdown in the site header to switch between them. No duplicate logins, no admin-side juggling, no lines crossing over between addresses.
— Header delivery selector
01 — Overview
Stock Odoo keys the cart to the customer. This module keys it to the destination.
Out of the box, website.sale_get_order looks carts up by (customer, website). A single portal user with five delivery locations gets one shared draft — add a line for location A, switch the shipping address to B, and those lines follow to B.
For wholesale buyers with separate physical sites — clinics, pharmacies, branches, warehouses, franchise stores — the one-cart model forces them to check out one location at a time and hope nothing crosses over.
This module keys the cart by (customer, shipping address, website) instead, so each address keeps its own open draft until the buyer is ready to submit it.
Everything else — pricelist resolution, fiscal position, payment-in-flight protection, abandoned-cart behavior, the confirmation flow — runs through stock Odoo code paths.
02 — What’s included
Seven changes, one coherent behavior.
F/01
Cart keyed by shipping address
sale_get_order is overridden to look up and create drafts per active delivery partner, not per customer alone.
F/02
Header delivery selector
Injected into portal.user_dropdown so it renders wherever the user menu appears. Hidden automatically when the buyer has fewer than two authorized addresses.
F/03
Session-driven active address
The active delivery survives navigation. On fresh login the most recent draft wins; if none exists, address_get(['delivery']) seeds it.
F/04
Mid-cart switch modal
Change address while the current cart has items and the user is offered Start new order, Move current cart, or Switch to existing cart.
F/05
Locked checkout picker
For multi-address users the in-checkout delivery-address selector becomes a read-only card pointing back to the header, so there’s one source of truth.
F/06
Collision-safe cart moves
If another tab has already created a draft at the destination, the move returns a structured error and the UI falls back to the switch-to-existing-cart flow.
F/07
Abandoned-cart GC
Per-website delay setting silently cancels draft carts older than N days. Payment-in-flight drafts are always skipped. Runs as a daily cron.
03 — How it works
One selector in the header, one draft per address. Everything else stays standard Odoo.
The active delivery address lives in the web session. sale_get_order is overridden to scope cart lookup to that session value, so each address resolves to its own draft.
Switching addresses from the header dropdown flips the session key; the cart badge and the checkout page re-render for the new address on next request. The module adds two JSON routes (/aglow/cart/set_active_delivery, /aglow/cart/move_to_delivery) and a small amount of QWeb.
— Switch modal
— Locked checkout picker
04 — Access & scope
Authorization follows the contact tree. Strictly.
A user’s authorized deliveries are the descendants of their parent_id with type = delivery, excluding the user themselves. Six hierarchy cases cover every topology you’re likely to model.
S/01 — standalone user
No parent, no dropdown.
Home customer signs up on the website. Stock Odoo flow, one cart, checkout picker shows their own address.
S/02 — parent, zero deliveries
Parent resolves as the address.
Acme Co → John. No dropdown. Checkout falls back to the parent company or the user — stock behavior.
S/03 — one delivery child
One option, single-location flow.
Acme Co → { John, Warehouse A }. No dropdown — it requires two. Checkout shows Warehouse A as the only option.
S/04 — primary use case
Two or more delivery children.
Acme Co → { John, Warehouse A, B, C }. Header dropdown lists all three; each has its own draft; the in-checkout picker is locked back to the header.
S/05 — nested under a delivery
Single-location by hierarchy.
Acme Co → Warehouse A → John. John can’t see B or C. Confines a user to one site without a separate company record.
S/06 — regional hub
Scoped to a subtree.
Acme → Region North → { Jane, N1, N2 }. Dropdown lists only N1 and N2. Gives regional managers multi-location shopping without exposing the full tree.
05 — Abandoned-cart cleanup
Old drafts close themselves. Payments-in-flight are never touched.
A per-website delay silently cancels draft carts older than N days. Drafts with a payment in flight are always skipped, so a checkout session in progress is never disturbed.
The cleanup runs as a daily cron. Configure the delay under Website → Configuration → Settings.
— Abandoned-cart setting
06 — Compatibility
Odoo 18. CE & EE. No third-party dependencies.
| Item | Value |
|---|---|
| Version | Odoo 18.0 |
| Editions | Community & Enterprise |
| Depends on | website_sale — no third-party modules, no external services |
| Configuration | Install — multi-delivery behavior activates automatically for portal users with two or more authorized addresses. Optional per-website abandoned-cart delay under Website → Configuration → Settings. |
| Safe for single-location | Zero visible change — the header dropdown only appears for buyers with two or more authorized addresses. |
07 — Support
A real engineer reads every email.
Email contact@aglow.dev
Per-Address Carts is developed and maintained by Alpenglow Technologies LLC. Provided “as is” without warranty of any kind.
Odoo Proprietary License v1.0 This software and associated files (the "Software") may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors, typically via Odoo Apps, or if you have received a written agreement from the authors of the Software (see the COPYRIGHT file). You may develop Odoo modules that use the Software as a library (typically by depending on it, importing it and using its resources), but without copying any source code or material from the Software. You may distribute those modules under the license of your choice, provided that this license is compatible with the terms of the Odoo Proprietary License (For example: LGPL, MIT, or proprietary licenses similar to this one). It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Please log in to comment on this module