Tuesday, July 14, 2020
18 changes · master
Enhancements to existing features
This update improves wording in the Survey app's management screens. The clearer labels should make survey setup and administration easier for users to understand, with no major workflow changes expected.
Original PR description
taskId 2285655 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Countries can now define whether a postal code or state is required when validating an address. This helps ensure contact addresses are complete enough for deliveries or mailings, while still allowing simple contact records without a street address.
Original PR description
After this commit, you can specify on a country, if zip or state is required to validate an address. We only check the constrains if the street if filled. We consider valid to have a res.partner located in a country without state on the record, if street is empty. The idea, is that we only need zip/state to send something to the contact, so a record withtout street == a contact, while a record with a street is an address and need to be 'valid' and have all information required to send a letter or a parcel. task-2172788 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now makes current date and time values more consistently available when evaluating business rules and screen logic. This helps modules such as Manufacturing show time-sensitive visual indicators more accurately, with minimal user disruption.
Original PR description
This PR handles 2 things: 1) the merging of the `py_utils.context()` into the evaluation context returned by `BasicModel._getEvalContext` to access the same time-related keys, 2) the addition of 2 new keys into the `py_utils.context` (thus transmitted to the basic model): `today` (an alias for the already present `current_date`) and `now` which represents the current date and time value. A first use case in the MRP module has also been applied to benefit from the new `now` key. Task 2269697
Odoo now shows the specific reason a translation file could not be loaded, instead of only saying the file could not be read. This helps administrators quickly identify issues such as a syntax error and line number, reducing troubleshooting time.
Original PR description
Before this commit Odoo would say that the translation file could not be loaded but not why. If we use, and include, the IOError the sysadmin can directly identify the issue. Let us take an example msgstr which has an issue: msgid "Website communication history" msgstr "Website communicatiegeschiedenis" 3 As you can see this contains an error because of the "3" here, which was added by accident. Before this commit you would only get "couldn't read translation file %s". After this commit it will pinpoint the issue with the line: odoo.tools.translate: couldn't read translation file [lang: nl][format: po]. Here's what we got back instead: Syntax error in po file (line 662) -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves the way Odoo's automated tests simulate dates and times, making test results more consistent and easier to maintain. It mainly affects accounting-related test coverage and supporting project dependencies, with no direct change expected for everyday users.
Original PR description
base, tests: use freezegun lib to mock dates and datetimes
This update improves automated checks for accounting-related features by using a more consistent way to simulate dates and times. It also adds extra coverage for Mexican electronic invoicing edge cases, helping reduce the risk of future regressions without changing day-to-day user workflows.
Original PR description
related to https://github.com/odoo/odoo/pull/54227
Users reviewing appraisal survey statistics can now navigate directly back to the related appraisal. This reduces extra clicks and makes the appraisal review flow smoother for HR teams and managers.
Original PR description
taskId 2285655
Resolved issues and error corrections
This update prevents the page editor from crashing when users drag and drop content on pages without a header. It makes the editing experience more reliable across websites and other editor contexts where a standard page header is not present.
Original PR description
Commit [1] introduced the bug by relying on the fact an element with id=top is in the edited DOM. As the website header can be disabled, this induced a crash as soon as the header was indeed disabled. Also, the editor is not meant to edit the website only so we cannot rely at all on the presence of a #top element. [1]: https://github.com/odoo/odoo/commit/6df67a28c2f113572acd4a3db19ab6b1bd37e7da
Miscellaneous changes
- bancontact (be; eur) - eps (at; eur) - giropay (de; eur) - p24 (pl; eur, pln) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#52855
Original PR description
- bancontact (be; eur) - eps (at; eur) - giropay (de; eur) - p24 (pl; eur, pln) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#52855
This fix ensures that template customizations build on earlier customizations instead of accidentally ignoring them. It improves consistency for screens and components that rely on layered template changes, reducing unexpected display differences.
Original PR description
[FIX] web: qweb inheritance Before this commit, defining a extension of a template by using the combination of directives 't-name' and 't-extend' ignored potential extensions that could have been…
[FIX] web: qweb inheritance
Before this commit, defining a extension of a template by using the
combination of directives 't-name' and 't-extend' ignored potential
extensions that could have been defined beforehand.
For instance, let's assume the following templates.
```xml
<t t-name="a">
<div><span>1</span></div>
</t>
<t t-extend="a">
<t t-jquery="span" t-operation="replace">
<span>2</span>
</t>
</t>
<t t-name="b" t-extend="a">
<t t-jquery="div" t-operation="append">
<span>b</span>
</t>
</t>
```
Rendering template "b" displayed "1b" whereas we would expect "2b".
Moreover, when the extended template is itself an extension of
another template:
```xml
<t t-name="a">
<div><span>a</span></div>
</t>
<t t-name="b" t-extend="a">
<t t-jquery="div" t-operation="append">
<span>b</span>
</t>
</t>
<t t-name="c" t-extend="b">
<t t-jquery="div" t-operation="append">
<span>c</span>
</t>
</t>
```
Rendering template "a" displayed "a", template "b" displayed "ab",
but template "c" displayed "ac", whereas we would expect "abc".
With this commit, other extensions done to a template are kept when
a new extension is defined. It relies on the templates order, and
takes into account all extensions that have *already* been defined.Contact cards now handle fields added below the city or country area more reliably. This prevents custom fields created with Studio from disappearing when both city and country are filled in, improving consistency for users customizing contact views.
Original PR description
Issue - Install "Studio" and "Contact" apps - Edit with Studio the Contact Kanban View - Add field under city/country Field appears only if no city is set. Cause The new field has as anchor the 5th <li> with the field country who will appear only if not city is set. However, in case there a city AND a country, the 6th <li> will appear instead of 5th (the target one). Solution Let only one <li>, one country and one city field but with the right conditions. opw-2288545
Forward-Port-Of: odoo/odoo#54428
Original PR description
Forward-Port-Of: odoo/odoo#54428
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#54416
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#54416
Description of the issue/feature this PR addresses: The wanted changes for ISR in 1 PR Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#54439 Forward-Port-Of: odoo/odoo#53815
Original PR description
Description of the issue/feature this PR addresses: The wanted changes for ISR in 1 PR Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#54439 Forward-Port-Of: odoo/odoo#53815
It has always been a best effort until the v13 to have false as default value for boolean field. Until v13: https://github.com/odoo/odoo/blob/12.0/odoo/models.py#L3645 During ORM refactoring in v13 it has been replaced by a default value in sql From v13: https://github.com/odoo/odoo/blob/13.0/odoo/tools/sql.py#L79 But with a typo since columntype for boolean is bool and not boolean. What's mean that in v13 we have a lot of null value for boolean (~=False) In all cases, we try to be
Original PR description
It has always been a best effort until the v13 to have false as default value for boolean field. Until v13: https://github.com/odoo/odoo/blob/12.0/odoo/models.py#L3645 During ORM refactoring in v13 it has been replaced by a default value in sql From v13: https://github.com/odoo/odoo/blob/13.0/odoo/tools/sql.py#L79 But with a typo since columntype for boolean is bool and not boolean. What's mean that in v13 we have a lot of null value for boolean (~=False) In all cases, we try to be aware and check Falsy boolean with 'null or False' (https://github.com/odoo/odoo/blob/13.0/odoo/osv/expression.py#L1230) So we should do the same when we write pure sql in method bypassing the ORM. Forward-Port-Of: odoo/odoo#53791 Forward-Port-Of: odoo/odoo#53325
Boolean value can be 'NULL' in database and not False. Related to https://github.com/odoo/odoo/pull/53325 Forward-Port-Of: odoo/enterprise#11502 Forward-Port-Of: odoo/enterprise#11296
Original PR description
Boolean value can be 'NULL' in database and not False. Related to https://github.com/odoo/odoo/pull/53325 Forward-Port-Of: odoo/enterprise#11502 Forward-Port-Of: odoo/enterprise#11296
Install account_invoice_extract Archive the cron Upgrade system --> Issue the cron is now active Note: on testing server we archive cron (we make a an SQL query before upgrade the system) @qdp-odoo @nim-odoo @sla-subteno-it Forward-Port-Of: odoo/enterprise#11320
Original PR description
Install account_invoice_extract Archive the cron Upgrade system --> Issue the cron is now active Note: on testing server we archive cron (we make a an SQL query before upgrade the system) @qdp-odoo @nim-odoo @sla-subteno-it Forward-Port-Of: odoo/enterprise#11320
Install account_online_sync Archive the cron Upgrade system --> Issue the cron is now active Note: on testing server we archive cron (we make a an SQL query before upgrade the system) @qdp-odoo @nim-odoo @sla-subteno-it Forward-Port-Of: odoo/enterprise#11318
Original PR description
Install account_online_sync Archive the cron Upgrade system --> Issue the cron is now active Note: on testing server we archive cron (we make a an SQL query before upgrade the system) @qdp-odoo @nim-odoo @sla-subteno-it Forward-Port-Of: odoo/enterprise#11318