Thursday, April 13, 2023
39 changes · master
Miscellaneous changes
The xmlid for the replacement contract type was not correct. Forward-Port-Of: odoo/enterprise#39616
Original PR description
The xmlid for the replacement contract type was not correct. Forward-Port-Of: odoo/enterprise#39616
The refusal notification was triggered for every applicant being archived, which whould fail when there was no referral user. Fixes #38554 task-3270054 Forward-Port-Of: odoo/enterprise#39625
Original PR description
The refusal notification was triggered for every applicant being archived, which whould fail when there was no referral user. Fixes #38554 task-3270054 Forward-Port-Of: odoo/enterprise#39625
The _validate_session() method in the l10n_de_pos_cert module was overridden without checking for a dictionary return value from the super method. This could cause unexpected behavior or errors when a redirection or a wizard was returned. For example, after calling the super function, it was possible that all orders were in the "paid" state and the session validation was not completed. This would cause the orders to be an empty recordset and generate errors when generating a template. Aft
Original PR description
The _validate_session() method in the l10n_de_pos_cert module was overridden without checking for a dictionary return value from the super method. This could cause unexpected behavior or errors when a redirection or a wizard was returned. For example, after calling the super function, it was possible that all orders were in the "paid" state and the session validation was not completed. This would cause the orders to be an empty recordset and generate errors when generating a template. After this commit it checks for a dictionary return value and returns it immediately if one is found, preventing the rest of the code from executing. This ensures that the code is only executed when it is appropriate to do so. opw-3265441 Forward-Port-Of: odoo/enterprise#39647
Current behaviour: The implementation of the `fetch_mail` function interogates the email server used for the EDI based on the IMAP uids. When first setting up the incoming email server record, the `l10n_cl_last_uid` used to track the last maximum uid that was processesed is set to 1. In pratice this leads to the function searching the IMAP server for mails from 1:*, i.e. a list of ALL IMAP uids is returned and a `for` loop is used to fetch one email at a time and validate the email attach
Original PR description
Current behaviour: The implementation of the `fetch_mail` function interogates the email server used for the EDI based on the IMAP uids. When first setting up the incoming email server record, the…
Current behaviour:
The implementation of the `fetch_mail` function interogates
the email server used for the EDI based on the IMAP uids. When first
setting up the incoming email server record, the `l10n_cl_last_uid` used
to track the last maximum uid that was processesed is set to 1.
In pratice this leads to the function searching the IMAP server for mails
from 1:*, i.e. a list of ALL IMAP uids is returned and a `for` loop is used
to fetch one email at a time and validate the email attachements for invoice
data. `l10n_cl_last_uid` gets updated outside the for loop to the last
processed uid in the current run.
The problem arises when the client connects to a new email server already
containing thousand of emails. In that case, while trying to process all
emails, the process will time out on the standard cpu limit (900s). Thus
the `for` loop never finishes and `l10n_cl_last_uid` never updates. At each
new run, the function begins from uid=1 again and timing out again.
After this fix:
We add a conservative default batch size (hardcoded to 50), so that the
`for` loop will only loop over the next 50 queued emails. Given an average
processing time of 2-3 seconds for each fetched email, this should guarantee
that the process never times out on current hardware and default settings.
As the default recurrence for the fetchmail cron job is "every 5 minutes",
we can expect that in most real life scenarios the clients DB should sync
in a matter of days maximum.
We also add a `server.write({'l10n_cl_last_uid': new_max_uid})` to the
try block relating to the email processing. This will keep track more often
of the last max processed IMAP uid in case the job is aborted for some other
unforseen reason.
opw-3225345
Forward-Port-Of: odoo/enterprise#39577ProgrammingError: can't adapt type 'pos.category' is generated when we follow below steps this is because the in search domain category_ids is required numbers(ids) but in function 'preparation_displays' was passed object. Steps to reproduce: 1) Install 'point_of_sale' module > Activate 'Preparation Display' from Configuration > Settings 2) Open pos session having preparation display like 'Bar'. 3) Create and validate a order > Close the session. 4) Click on 'Orders' > 'Preparation Disp
Original PR description
ProgrammingError: can't adapt type 'pos.category' is generated when we follow below steps this is because the in search domain category_ids is required numbers(ids) but in function 'preparation_displays' was passed object.
Steps to reproduce:
1) Install 'point_of_sale' module > Activate 'Preparation Display' from
Configuration > Settings
2) Open pos session having preparation display like 'Bar'. 3) Create and validate a order > Close the session. 4) Click on 'Orders' > 'Preparation Display' and select 'Open Display' according
to order.
5) Click on order item and the error will be generated in backend.
See:
By applying this, `categories.ids` will be passed instead of `category`.
sentry - 4063535802
Forward-Port-Of: odoo/enterprise#39485In https://github.com/odoo/enterprise/pull/35050 we created hooks throughout the checkout process in order to easily pass values to localization-specific templates. (for example, `_cart_values()`). Now that several localizations are customizing the checkout process (in particular Chile, see https://github.com/odoo/enterprise/pull/38737) all the hooks need to be called (via inheritance) meaning that they all need to call `super()`. So this fixes the few hooks that don't yet call super(). F
Original PR description
In https://github.com/odoo/enterprise/pull/35050 we created hooks throughout the checkout process in order to easily pass values to localization-specific templates. (for example, `_cart_values()`). Now that several localizations are customizing the checkout process (in particular Chile, see https://github.com/odoo/enterprise/pull/38737) all the hooks need to be called (via inheritance) meaning that they all need to call `super()`. So this fixes the few hooks that don't yet call super(). Forward-Port-Of: odoo/enterprise#39428
The custom handler linked to this report was missing the override of _dynamic_lines_generator, necessary in order not to load the lines of the generic tax report on top of the ones defined by account.report.line objects for this report. Forward-Port-Of: odoo/enterprise#39623
Original PR description
The custom handler linked to this report was missing the override of _dynamic_lines_generator, necessary in order not to load the lines of the generic tax report on top of the ones defined by account.report.line objects for this report. Forward-Port-Of: odoo/enterprise#39623
Partner name not filled when importing CAMT.053 files from UNICREDIT. Forward-Port-Of: odoo/enterprise#37503
Original PR description
Partner name not filled when importing CAMT.053 files from UNICREDIT. Forward-Port-Of: odoo/enterprise#37503
…r b2b before this commit ================== if line note or line section is added in invoice then wrong json is prepared there is multi line for same tax then GSTR-1 b2b json value is only take first line value after this commit: ================== ignore line note and line section in report sum all line value with same tax for GSTR-1 B2B Forward-Port-Of: odoo/enterprise#39580
Original PR description
…r b2b before this commit ================== if line note or line section is added in invoice then wrong json is prepared there is multi line for same tax then GSTR-1 b2b json value is only take first line value after this commit: ================== ignore line note and line section in report sum all line value with same tax for GSTR-1 B2B Forward-Port-Of: odoo/enterprise#39580
Steps to reproduce: - install and use the French language; - create a contract based on planning for an employee; - create a planning for this employee; - publish the planning; - create a payslip; - select the employee; - change the dates to correspond to the period. Issue: Example for the month of March: `ValueError: time data '01 mars 2023' does not match format '%d %b %Y'` Solution: Use the same solution as for the "hr_payroll_attendance" module: ccfa0a60f1702f464f4b4bdd7caf61
Original PR description
Steps to reproduce: - install and use the French language; - create a contract based on planning for an employee; - create a planning for this employee; - publish the planning; - create a payslip; - select the employee; - change the dates to correspond to the period. Issue: Example for the month of March: `ValueError: time data '01 mars 2023' does not match format '%d %b %Y'` Solution: Use the same solution as for the "hr_payroll_attendance" module: ccfa0a60f1702f464f4b4bdd7caf616d7ceff349 Important remark: It is a direct manager who is in the same timezone who manages the employee's planning. opw-3252214 Forward-Port-Of: odoo/enterprise#39413
This commit fixes the api.depends to the 'auth_totp' module which isnt a dependency. And it also fix an error cause by missing client-data when loading the wizard (due to multifactor header). original PR: https://github.com/odoo/enterprise/pull/38060 task-2925880 Forward-Port-Of: odoo/enterprise#39326 Forward-Port-Of: odoo/enterprise#38912
Original PR description
This commit fixes the api.depends to the 'auth_totp' module which isnt a dependency. And it also fix an error cause by missing client-data when loading the wizard (due to multifactor header). original PR: https://github.com/odoo/enterprise/pull/38060 task-2925880 Forward-Port-Of: odoo/enterprise#39326 Forward-Port-Of: odoo/enterprise#38912
Changing the typo in label 'Time based pricing' to 'Time-based pricing' (with a hyphen) on the product form. Task-id: 3264238 Forward-Port-Of: odoo/enterprise#39366
Original PR description
Changing the typo in label 'Time based pricing' to 'Time-based pricing' (with a hyphen) on the product form. Task-id: 3264238 Forward-Port-Of: odoo/enterprise#39366
issue: Before this commit, in the portal view of tickets while closing tickets the wizard open was under the tab of the website navbar. So in this commit, add the top margin to make the ticket close dialog visible under the navbar. task-2954190 Forward-Port-Of: odoo/enterprise#30890
Original PR description
issue: Before this commit, in the portal view of tickets while closing tickets the wizard open was under the tab of the website navbar. So in this commit, add the top margin to make the ticket close dialog visible under the navbar. task-2954190 Forward-Port-Of: odoo/enterprise#30890
- Helpdesk: remove extra blank space in tip of the helpdesk tour - Planning: fix the planning tour task-3099432 Forward-Port-Of: odoo/enterprise#39532 Forward-Port-Of: odoo/enterprise#35260
Original PR description
- Helpdesk: remove extra blank space in tip of the helpdesk tour - Planning: fix the planning tour task-3099432 Forward-Port-Of: odoo/enterprise#39532 Forward-Port-Of: odoo/enterprise#35260