-
-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[17.0][MIG] crm_event: Migration to version 17.0 #414
Conversation
This module extends the functionality of CRM opportunities (and leads, if enabled) to support linking them to event types and to allow you to keep track of leads interested in an upcoming event of some type. This is useful if you organize your events based on the amount of people interested in a certain type of event. @Tecnativa TT27664 [UPD] Update crm_event.pot [UPD] README.rst [ADD] icon.png
- Upstream merged both lead and opportunity form views. @Tecnativa TT31318
It complies with the requirements and is needed by manifestoo.
The company field isn't mandatory for event types, so we have to check that a lead auto invites to events available in the company of the lead. We also have to check the proper base_url for our template. When we have multi-website we want our customer going to the right link, otherwise they'd be getting confusing info. TT36027
Currently translated at 100.0% (40 of 40 strings) Translation: event-15.0/event-15.0-crm_event Translate-URL: https://translation.odoo-community.org/projects/event-15-0/event-15-0-crm_event/it/
Currently translated at 100.0% (40 of 40 strings) Translation: event-15.0/event-15.0-crm_event Translate-URL: https://translation.odoo-community.org/projects/event-15-0/event-15-0-crm_event/es/
c8d1903
to
0892ba3
Compare
/ocabot migration crm_event |
crm_event/models/event_type.py
Outdated
for group in results: | ||
event_type = group["event_type_id"][0] | ||
events = self.env["event.event"].search( | ||
[ | ||
("event_type_id", "=", event_type), | ||
("date_end", ">=", fields.Date.today()), | ||
] | ||
) | ||
total_seats = sum(event.seats_available for event in events) | ||
group["seats_available"] = total_seats |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO this should not be necessary, the seats_available
field is already being used in read_group and the domain as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the solution is to remove the read_group
for the totals calculation because the seats_available
field in v17 is not stored and operates directly on data stored in the database.
0892ba3
to
be873cd
Compare
This migration removes the `read_group` for event totals calculation in the _compute_event_total method because the `seats_available` field in v17 is not stored (`compute` and `store=False`). This makes `read_group` unable to correctly process and calculate the value of the `seats_available` field, as it operates directly on data stored in the database. Instead, a manual calculation is implemented which: - Iterates over the filtered events according to the domain. - Groups the data by `event_type_id`. - Calculates the total number of available seats and the number of events associated with each type. TT51918
be873cd
to
d402de3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested and working
/ocabot merge nobump |
Hey, thanks for contributing! Proceeding to merge this for you. |
This PR has the |
Congratulations, your PR was merged at bfaafae. Thanks a lot for contributing to OCA. ❤️ |
cc @Tecnativa TT51918
@chienandalu @victoralmau please review