[eduezerouali-tecnativa]

cc @Tecnativa TT59949
This modulo allows to not store the address on checkout. Once transaction is confirm it will archive the contact. It is meant for customers that are dropshippers and have lots of addresses.
ping @juancarlosonate-tecnativa @sergio-teruel

pending:

• add test

[pedrobaeza]

I don't know the exact implementation of this, but the name doesn't seem the best. A more accurate one may be website_sale_checkout_address_no_save or maybe website_sale_checkout_temp_address, but as said, it depends on the implementation.

@eduezerouali-tecnativa please recheck all the sentences, as they contain incorrect English and even your name is not correctly spelled. It's good to read things twice in these cases.

[eduezerouali-tecnativa]

@pedrobaeza you are right. I changed the name to website_sale_checkout_address_no_save; it seems more accurate.
This module is intended to avoid having too many addresses during checkout. For example, if my customer serves other customers, they might not need to have that address saved, as it may not be a regular customer. In that case, when editing the address, they can choose to archive it after the checkout is completed.

Additionally, when a user enters the details for another address, if the phone, email, ZIP code, and street match an archived contact, the module reactivates that contact instead of creating a new one. Al thought I do not think this will happened very often.

I did add the test but the tour to work depends on this PR #1162.

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

[rrebollo]

Hi @eduezerouali-tecnativa — thanks for the module! I've left a few small suggestions inline; none of them is blocking. Would you mind having a look and pinging me once you've considered them, so I can review again?
I think you need to squash your commits into a single one.
In return, would you be so kind as to review my PR? Thank you!
OCA/e-learning#20

[rrebollo]

AGPL-3.0 is declared in the manifest, but the file headers link to the LGPL text (http://www.gnu.org/licenses/lgpl.html) — the same in __init__.py:2, controllers/__init__.py:2, controllers/main.py:2 and tests/test_checkout_address_no_save.py:2. The URL should match the declared license; the OCA module template uses # License AGPL-3.0 or later (https://www.gnu.org/licenses/agpl).

[rrebollo]

The module was renamed to website_sale_checkout_address_no_save, but the manifest still carries the old name and a summary with typos:

"name": "Website Sale Not Save Address",
"summary": "Avoid having to many address as dropshipping customer",

Suggest e.g. "name": "Website Sale Checkout Address No Save" and "summary": "Do not keep the addresses created during checkout".

[rrebollo]

Minor consistency: @route is used here, while display_status below uses @http.route (line 63).

[rrebollo]

Question: reactivating a previously archived contact (searching inactive children by email/phone/street and setting active = True below) isn't mentioned in the README/USAGE. Is it intended as part of this feature, or should it be documented?

[rrebollo]

archived_child.write({"active": True, **form_data}) spreads the raw form data into res.partner.write. It carries keys that aren't writable fields on res.partner (csrf_token, archive_address) plus the string country_id/state_id, so this raises. Core separates the address fields from the rest before writing — please reactivate with an explicit whitelist of address fields.

[rrebollo]

Question: the description says the contact is archived once the transaction is confirmed, but this runs on any /payment/status render — the session flag is popped and sale_last_order_id is used with no check on the related payment.transaction. Could /payment/status be reached without a successful payment (the test at tests/test_checkout_address_no_save.py:123 seems to do just that)? If so, should the archiving be gated on the transaction state?

[rrebollo]

This second tour is a near-verbatim copy of the first (tour.esm.js:7): both repeat the search → add-to-cart → fill-address-twice sequence and only differ in the last step (~90 duplicated lines). Consider extracting the shared steps.