Daily updates from Odoo
Navigate
Branch
Friday, November 20, 2020
16 changes
Enhancements to existing features
Approval records now mark key identifier fields as required when they are created locally. This helps prevent incomplete approval data and reduces the risk of record creation issues for users working with approvals.
The Appraisal app now displays goal form field values more cleanly on mobile devices. This makes reviews easier to read and use on smaller screens and helps avoid a mobile status button display error.
Original PR description
PURPOSE
Improve Mobile UI of Appraisal
SPECIFICATIONS
Goals Form
Appraisal Form
If using the Status button => Error:
Uncaught Error: Please use show on visible elements
Traceback:
Error: Please use show on visible elements
at Tooltip.show
at Tooltip.$.fn.tooltip.Constructor.show
LINKS:
PR - #14869
TaskID - 2348528Belgian payroll users can now select the work entry type directly when running the time credit wizard, instead of relying on a fixed setting on the contract structure type. This makes time credit setup more flexible and removes an older configuration field that is no longer needed.
Original PR description
…izard
Before this commit:
* The work entry type used to fill the employee calendar for the time credit intervals
was the one specified in the structure_type_id.time_credit_type_id field of the contract.
After this commit:
* The work entry type used to fill the employee calendar for the time credit intervals
can be specified during the credit time wizard.
* The structure_type_id does not have the time_credit_type_id field any more.
Related PR: odoo/upgrade#1881
task-2367915This update improves how several Odoo apps validate records when multiple items are created or updated at once. It reduces the risk of validation errors, removes duplicate checks, and improves performance in affected workflows without changing day-to-day features.
Original PR description
PURPOSE
Perform a cleaning of constraints in various applications to improve
coding style and performances.
SPECIFICATIONS
Support multi recordsets. Otherwise constraints may crash or
be incorrectly applied when creating or updating recordsets
containing more than one item.
Improve performances
* early raise if a constraint is invalid; avoid looping on whole
recordset if not necessary;
* use ORM methods completely (notably _check_recursion
allowing batch directly);
* remove duplicates when having both python and SQL constraints;
* avoid unnecessary calls, notably ref in loops;
LINKS
Task Id: 2328664
COM PR: odoo/odoo#55525
ENT PR: odoo/enterprise#12250Belgian payroll can now calculate private car reimbursements and representation fees based on eligible attendance entries. This helps ensure these benefits are prorated more accurately when employees have absences, leave, or partial work schedules.
Original PR description
Before this commit:
Private car reimbursement and representation fees were not paid on
the base of attendance
After this commit:
It will be possible to set that a work entry give rights to reimbursement
for:
* private car reimbursement
* representation fees
The slip computation will be based on that and those amounts will
be prorated according to the work entries for which the setting has
been activated.
Related PR: odoo/odoo#60119, odoo/upgrade#1876
task-2346119Code cleanup and technical improvements
Bank account synchronization has been rewritten to use Odoo's own Finance proxy service instead of direct connections to third-party providers. This makes it easier to manage provider changes centrally and should improve reliability and maintainability for customers using online bank feeds.
Original PR description
All code refering to third party services (plaid, yodlee, ponto) has now moved on a specific proxy. We've created our own API services to fetch accounts and transactions and this module implements it.
Miscellaneous changes
- Archive an employee - Go to Payroll / Payslips / Batches - Generate Payslips - Add an archived employee The payslips are not generated. It happens because archived records are not taken into account by default. opw-2380649 Forward-Port-Of: odoo/enterprise#14876
Original PR description
- Archive an employee - Go to Payroll / Payslips / Batches - Generate Payslips - Add an archived employee The payslips are not generated. It happens because archived records are not taken into account by default. opw-2380649 Forward-Port-Of: odoo/enterprise#14876
In the report editor, BooleanField is an Owl component but would: - never be isMounted because it was not in DOM when `mount` was used - not send expected structure of event to AbstractEditComponent because _onDirectiveChange was expecting event from old type of widget. With this changeset, we add special cases for Owl component so clicking on a checkbox (eg. "Display only the date" option for a datetime field) do what is expected (enable or disable the option). Without the chan
Original PR description
In the report editor, BooleanField is an Owl component but would: - never be isMounted because it was not in DOM when `mount` was used - not send expected structure of event to AbstractEditComponent because _onDirectiveChange was expecting event from old type of widget. With this changeset, we add special cases for Owl component so clicking on a checkbox (eg. "Display only the date" option for a datetime field) do what is expected (enable or disable the option). Without the change, the added test fails because the assertion: "Toggling no_marker checkbox should change the option value" is never run. opw-2381667 Forward-Port-Of: odoo/enterprise#14862
Without this change, if the user somehow got the MapBox api token wrong, the settings would not work anymore because the initial onchange was interrupted with UserError. Now the check on the token is done when writing settings, so if there is an issue in the token, it is possible to fix it using settings that still work. opw-2374033 Forward-Port-Of: odoo/enterprise#14770
Original PR description
Without this change, if the user somehow got the MapBox api token wrong, the settings would not work anymore because the initial onchange was interrupted with UserError. Now the check on the token is done when writing settings, so if there is an issue in the token, it is possible to fix it using settings that still work. opw-2374033 Forward-Port-Of: odoo/enterprise#14770
- Install sale_suscription - Go to Subscriptions > Configuration > Subscriptions Template - Create a Template with Payment Mode set to "Invoice only on successful payment" - Create a Subscription: * Subscription Template: [created Template] * Payment Token: [i.e. use a registered card for Stripe] - Save and change state to "In Progress" - Make sure that "Date of Next Invoice" is earlier than current day - Go to Settings > Technical > Scheduled Actions - Run manually "Sale Subscripti
Original PR description
- Install sale_suscription - Go to Subscriptions > Configuration > Subscriptions Template - Create a Template with Payment Mode set to "Invoice only on successful payment" - Create a Subscription: * Subscription Template: [created Template] * Payment Token: [i.e. use a registered card for Stripe] - Save and change state to "In Progress" - Make sure that "Date of Next Invoice" is earlier than current day - Go to Settings > Technical > Scheduled Actions - Run manually "Sale Subscription: generate recurring invoices and payments" On Subscription, an Invoice has been created and sent, but it is a draft. The invoice is sent before being posted. opw-2374792 Forward-Port-Of: odoo/enterprise#14878 Forward-Port-Of: odoo/enterprise#14614
Behavior prior to this commit: - when reconciling a line with a tax that has associated tags, an error message about invalid field is shown (for example, using the Bank Fees with 21% VAT on a Belgian company) - this is due to the fact that the tag is not properly passed to the front-end code, thus the front-end code sends back a null tag to the server Behavior after this commit: - the tax tag is sent properly, and there is no error message when reconciling the statement line op
Original PR description
Behavior prior to this commit: - when reconciling a line with a tax that has associated tags, an error message about invalid field is shown (for example, using the Bank Fees with 21% VAT on a Belgian company) - this is due to the fact that the tag is not properly passed to the front-end code, thus the front-end code sends back a null tag to the server Behavior after this commit: - the tax tag is sent properly, and there is no error message when reconciling the statement line opw-2381044 Forward-Port-Of: odoo/enterprise#14782
## Issue: If the `PAC` is set as "SW sapien-SmarterWEB", the payments or invoices with `Electronic invoicing: Sent` cannot be open ## Cause: The document data is base64 encoded twice during the synchronization procedure [First encoding during fetching CFDI response](https://github.com/odoo/enterprise/blob/62e7d0a7c583aa7ba19a62592e5b4959e6d9f965/l10n_mx_edi/models/account_edi_format.py#L704): `cfdi = base64.encodebytes(response_json['messageDetail'].encode('UTF-8'))` [Second encodin
Original PR description
## Issue:
If the `PAC` is set as "SW sapien-SmarterWEB", the payments or invoices with `Electronic invoicing: Sent` cannot be open
## Cause:
The document data is base64 encoded twice during the synchronization procedure
[First encoding during fetching CFDI response](https://github.com/odoo/enterprise/blob/62e7d0a7c583aa7ba19a62592e5b4959e6d9f965/l10n_mx_edi/models/account_edi_format.py#L704): `cfdi = base64.encodebytes(response_json['messageDetail'].encode('UTF-8'))`
[Second encoding during generating attachment](https://github.com/odoo/enterprise/blob/62e7d0a7c583aa7ba19a62592e5b4959e6d9f965/l10n_mx_edi/models/account_edi_format.py#L909): `cfdi_attachment = self._create_payment_cfdi_attachment(move, base64.encodebytes(res['cfdi_signed']))`
## Solution:
Check `cfdi_encoding` before the document generation
opw-2379963
Forward-Port-Of: odoo/enterprise#14797it is currently impossible to modify the creation of the accounting entry. this commit allows at least to replace the new function `action_create_account_move `without altering the behavior of `action_payslip_done`. To avoid many differences, it is proposed this way, but it could segregate more functions as: `_prepare_account_move`... `_prepare_account_move_lines`... @tivisse can you review and merge if possible please? Forward-Port-Of: odoo/enterprise#13357
Original PR description
it is currently impossible to modify the creation of the accounting entry. this commit allows at least to replace the new function `action_create_account_move `without altering the behavior of `action_payslip_done`. To avoid many differences, it is proposed this way, but it could segregate more functions as: `_prepare_account_move`... `_prepare_account_move_lines`... @tivisse can you review and merge if possible please? Forward-Port-Of: odoo/enterprise#13357
Priori to this commit: * The work entries dates used in the query where used in their UTC form during daily aggregation, which could potentially lead to wrong data (if date_start and/or date_stop where between 00:00 and 01(02):00 during winter(summer) time. After this commit: * The work entries dates will be 'timezoned' to their associated contract time zone. Forward-Port-Of: odoo/enterprise#14846
Original PR description
Priori to this commit:
* The work entries dates used in the query where used in their
UTC form during daily aggregation, which could potentially lead
to wrong data (if date_start and/or date_stop where between
00:00 and 01(02):00 during winter(summer) time.
After this commit:
* The work entries dates will be 'timezoned' to their associated
contract time zone.
Forward-Port-Of: odoo/enterprise#14846Makes no sense to be readonly Forward-Port-Of: odoo/enterprise#14849
Original PR description
Makes no sense to be readonly Forward-Port-Of: odoo/enterprise#14849
Prior to this commit: * In _generate_work_entries, when force_work_entry_generation is present in the context, no check was made that the date_from and date_to were within the contract date_start and date_stop interval. After this commit: * The data_from and date_to params will be adapted according to the contract date_start and date_stop if needed. Forward-Port-Of: odoo/enterprise#14871
Original PR description
Prior to this commit:
* In _generate_work_entries, when force_work_entry_generation is present
in the context, no check was made that the date_from and date_to were
within the contract date_start and date_stop interval.
After this commit:
* The data_from and date_to params will be adapted according to the contract
date_start and date_stop if needed.
Forward-Port-Of: odoo/enterprise#14871