[18.0][MIG] event_sale_reservation: Migration to 18.0#436
[18.0][MIG] event_sale_reservation: Migration to 18.0#436BhaveshHeliconia wants to merge 18 commits into
Conversation
|
/ocabot migration event_sale_reservation |
ee9bcb8 to
e23e442
Compare
|
Hey @OCA/crm-sales-marketing-maintainers would be great if someone could have a look at this module. |
e23e442 to
fe38b34
Compare
|
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. |
github-actions
Bot
added
the
stale
fe38b34 to
f62cc7e
Compare
|
Hey @OCA/e-learning-maintainers would be great if someone could have a look at this module. |
| _inherit = "product.template" | ||
|
|
||
| detailed_type = fields.Selection( | ||
| type = fields.Selection( |
There was a problem hiding this comment.
Shouldn't be better to use service_tracking?
A migration script might be needed
There was a problem hiding this comment.
I’ve updated it as per your suggestion and used service_tracking. Thanks for your suggestion. Kindly please review.
github-actions
Bot
removed
the
stale
|
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. |
github-actions
Bot
added
the
stale
This module extends the functionality of event_sale to support selling reservations of events that still don't exist and to allow you to schedule the creation of events based on how many reservations already exist. Includes integration workaround to avoid test conflicts with `event_sale_registration_multi_qty`. @Tecnativa TT27664 [UPD] Update event_sale_reservation.pot [UPD] README.rst
TT31321 [UPD] Update event_sale_reservation.pot [UPD] README.rst
Currently translated at 100.0% (32 of 32 strings) Translation: event-15.0/event-15.0-event_sale_reservation Translate-URL: https://translation.odoo-community.org/projects/event-15-0/event-15-0-event_sale_reservation/it/
Currently translated at 100.0% (32 of 32 strings) Translation: event-15.0/event-15.0-event_sale_reservation Translate-URL: https://translation.odoo-community.org/projects/event-15-0/event-15-0-event_sale_reservation/it/
Currently translated at 100.0% (32 of 32 strings) Translation: event-15.0/event-15.0-event_sale_reservation Translate-URL: https://translation.odoo-community.org/projects/event-15-0/event-15-0-event_sale_reservation/es/
Currently translated at 100.0% (32 of 32 strings) Translation: event-17.0/event-17.0-event_sale_reservation Translate-URL: https://translation.odoo-community.org/projects/event-17-0/event-17-0-event_sale_reservation/it/
b9f2359 to
e3b3929
Compare
OCA-git-bot
added
series:18.0
mod:event_sale_reservation
|
ping @etobella |
| def _onchange_service_tracking_event_reservation(self): | ||
| if self.service_tracking == "event_reservation": | ||
| self.type = "service" | ||
| self.invoice_policy = "order" |
There was a problem hiding this comment.
IMHO, this conflicts with _compute_invoice_policy(). You should override that function instead for this field.
There was a problem hiding this comment.
Thank you for the review and for raising this point.
I took another look at the implementation, and I believe the current onchange approach is the correct one and does not conflict with _compute_invoice_policy().
My reasoning is as follows:
-
It follows the Odoo core implementation
In Odoo 18 (event_sale), _onchange_type_event sets self.invoice_policy = "order" inside an @api.onchange("service_tracking") for the event tracking type. This module follows the same pattern for event_reservation. -
There is no runtime conflict with _compute_invoice_policy()
_compute_invoice_policy() depends only on type, not on service_tracking. Additionally, it only assigns a value when invoice_policy is not already set, so the value assigned by the onchange is preserved and is not overwritten. -
The field is intentionally designed to be overridable
The field is defined as store=True and readonly=False. This is the pattern used by Odoo to provide a computed default while still allowing users or onchange methods to override the value when needed. Moving this logic into a compute override would remove that flexibility and unnecessarily diverge from the core implementation.
For these reasons, I believe it is best to keep the current implementation, as it remains consistent with the Odoo core approach.
github-actions
Bot
removed
the
stale
11 participants
No description provided.