Some theme are enabling an header template. When doing so, they also disable
the default header template.
But this is not enough, as the user could have changed that template and it is
not the default one anymore.
Then, updating that theme (UX, CLI, Migration) will raise a traceback.
Step to reproduce:
- Create a website and install theme avantgarde
- Enter edit mode and select Magazine header template
At that point, update the theme, either:
- Through the UI, on theme switch screen, click on Update
- Through CLI, just run a `-u theme_avantgarde`
-> A traceback will be raised about an xpath error, as both the magazine header
template and the hamburger header template are active at the same time. Only
one template is supposed to be activated.
The issue also impact migration, as migrated website can't be accessed due to
the xpath error on rendering.
Theme being impacted (at least): Avantgarde, Graphene & Nano
Note that when installing one of those themes for the first time on a website,
the error won't occur as `_reset_default_config()` will be called through
`_theme_remove()`.
Note that this fix will ensure the correct template is set (and all others are
disabled), but the scss variable won't be correctly set (as it would be if that
template change was done through the right panel).
This is not that much of a problem (considering what it solves), any later
change from the user through the right panel will solve that mismatch.
Fixes https://github.com/odoo/upgrade/pull/3048
task-2593407
opw-2680866
opw-2685951
opw-2685124
opw-2679040
X-original-commit: f18cd32a936829d8a059db0d259189503ee5317f
Part-of: odoo/odoo#81953
As the message is thought to be posted in chatter replacing returns with html break.
closesodoo/odoo#81937
X-original-commit: 6cb616d74f71951b3989880ae232702d2257d292
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Wolfgang Taferner <w.taferner@wtioit.at>
A portal user couldn't download a survey certificate
Steps to reproduce:
1. Install the Survey app and open it
2. Create a survey with a scoring and a certificate and copy the link
3. In an incognito tab, connect as portal and go to the survey
4. After completing the survey, try to download the certificate
Solution:
Change the call 'sudo()' to 'with_user(SUPERUSER_ID)'
OPW-2687625
closesodoo/odoo#81957
X-original-commit: 962919ec878b4e93b4dd8f01f029ce1366976d9b
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
The dutch COA is outdated and incomplete. Some accounts have wrong types, and some accounts are missing.
Correct the COA so that every account is correctly categorized.
Changes:
- Add and correct accounts in the dutch COA
- Add tag to 'bank suspense account'
Task id=2674603
closesodoo/odoo#81943
X-original-commit: d486d26cbd705cc5a2bff074d26308c0ecc9d798
Related: odoo/enterprise#23115
Signed-off-by: Laurent Smet <las@odoo.com>
Before, the system required a vat number on every partner, but that
is not required. We need to send it as some other kind of ID however.
To clarify, a partner without vat is not for the simplified case only.
closesodoo/odoo#81942
X-original-commit: 2b164b8e5173ebbc80b8662a011ec48a7a06bcf5
Signed-off-by: Laurent Smet <las@odoo.com>
It's possible to confirm an invoice with an archived bank account of
the recipient. But it's not making any sense, since the bank account
is archived.
It's why we need to raise an error if the user want to confirm an
invoice with an archived bank account.
opw-2704605
closesodoo/odoo#81939
X-original-commit: 8b9ff034cb67b132cdb6736a5f18d70beb63c253
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Bruno-brsy <brsy@odoo.com>
Current behavior :
PDF Preview in document layout settings doesn't match the downloaded one (colors of div with the total and the columns displayed)
Steps to reproduce :
- Go to Settings
- 'Configure Document Layout' under Companies
- Set layout to Boxed
- Change the colors
- Download the PDF Preview
Reason :
- The columns for the unit price and taxes had the 'd-none' class so they weren't visible when printing the pdf preview. To keep coherence, if we see them in the preview we must see them in the pdf.
- Colors, especially the total div with a 'Boxed' layout, weren't taken into account for some elements in the preview. This is due to a character sanitized in the CSS, specifically '>' which becomes '>' for the '.row > div > table' selector.
OPW-2716089
closesodoo/odoo#81932
X-original-commit: 158c0ae425b3be446d81c3a6f4387b2d9426d10e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Claude Thibault (thcl) <thcl@odoo.com>
In case the product is tracked and the "Ship Later" feature is enabled,
the lots defined on the POS order are not the same that the ones on the
SMLs of the associated picking
To reproduce the issue:
(Use demo data)
1. Create a product P:
- Type: Storable
- Tracked by lots
- Available in POS
2. Update P's quantity:
- 2 x Lot01
- 2 x Lot02
3. Edit the existing POS:
- Enable the "Ship Later" feature
4. Start a POS session
5. Add some products:
- 1 x P (Lot01)
- 1 x p (Lot02)
6. Process the order with the option "Ship Lated" selected
7. Open the associated delivery order
Error: The reserved lots are incorrect: 2 x Lot01 instead of 1 x Lot01 +
1 x Lot02
When creating such a POS order, if the feature "Ship Later" is used, a
method creates a procurement for each POS order line thanks to
`_launch_stock_rule_from_pos_order_lines`
https://github.com/odoo/odoo/blob/72d6431eb26654b697fc0379f4b6d7e305bb79fc/addons/point_of_sale/models/pos_order.py#L677-L680
Then, these procurements are managed by the standard process, which does
not consider the defined lots. This is the reason why it simply uses the
available quantity in the first lot.
OPW-2704352
closesodoo/odoo#81888
X-original-commit: bc59c4eb7ef6bc216474f39ef8e2634b4ab5ff42
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Part of code in `_create_move_from_pos_order_lines` ensures the creation
of the SMLs based on the SN defined from the POS session
Extracting this part of the code enables the creation of these SML on
already-created SM
Linked to OWP-2704352
X-original-commit: 648232a9b34324bbfe86e2c4cb69db127fe48a7a
Part-of: odoo/odoo#81888
Step to reproduce:
- Have a fleet contract that need renewal
Current Behaviour:
- A new activity is created everytime the scheduler is called
Behaviour after PR:
- A new activity is only created if there is no current renewal activity present when the scheduler is called
opw-2713537
closesodoo/odoo#81919
X-original-commit: 3610069ea2c10fccf8fcc82c384a2194c4702e06
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Steps to reproduce:
- Create two bank journals Bank-1 and Bank-2
- Create one Oustanding Payments and one Outstanding Receipts account for each bank journal
- Create and confirm an internal tranfer from Bank-1 to Bank-2 for 100$
- A second payment is created
Issue:
The account on the line in the second payment is the Outstanding Payments account of Bank-1,
it should be the Outstanding Receipts account of Bank-2.
After this commit, the second payment will take into account the account set on bank journal,
and if not set, the one set on company. Otherwise, an error is raised.
opw-2711252
closesodoo/odoo#81938
X-original-commit: 51b5a9d4e56d8d2300cf1ee91f8030c57a41a856
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>
This PR allows the user to put a transparency effect on the mega menu.
The transparency effect did not work on the mega menu because
the container that contains the mega menu did not have transparency.
Note that the mega menu templates use a default background color
since [1] to not be transparent by default because of this commit.
[1]: 967d21a
task-2623335
closesodoo/odoo#77871
Related: odoo/upgrade#2929
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Error raised when trying to add the Wire Transfer payment method in eCommerce
Steps to reproduce:
1. Install the eCommerce app
2. Open the Website app
3. Click on "Set payments" on the eCommerce Dashboard
4. Select "Custom payment instructions", fill in the fields and save
Solution:
Remove the piece of code that raised the error
OPW-2687671
closesodoo/odoo#81929
X-original-commit: 25e153ab652f7a4bcc70e145b47bc138d9fb3790
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Invalid data provided at record creation were silently skipped by the
framework without triggering an error. This commit ensures that data are
no longer accidentally filtered and therefore that an error will be
raised if a key that does not match an actual field is provided.
This commit also removes the dead code that was detected thanks to these
changes.
closesodoo/odoo#81909
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Those were not accounted for, leading to fstrings passing through
unflagged.
Also update the SQL checker to be stricter but smarter:
The previous version would "fail open", unknown nodes would be allowed
through hence f-strings not being flagged when they started appearing
in arg0 position, should now fail-closed, anything that's not allowed
is forbidden.
This flags a few more cases, all of which seem acceptable upon review.
However the previous version would also only resolve arg0 (in case it
had a `NAME`, to see if that resolved to an acceptable form of
query-building). The new version performs resolution during
`_check_concatenation` and should thus allow e.g. format strings to be
separate variables (though not e.g. module-level constants, yet
anyway).
In resolution, replace the ad-hoc process by astroid's built-in
`lookup` which seems to provide the same information. Slightly more in
fact, as it yields every assignment in case of e.g. conditionals, but
making use of that would require a lot more changes in the checker so
leaving the behaviour as-is for now.
It's important to *not* use `ilookup` here, because ilookup is not
"iterable" but "inferring", and we don't want values, we want
expression ASTs for analysis.
NOTE: previous improvements as well as fixes to existing code were
only implemented in 14.0, hence this being merged in 14.0 not 13.0
despite 13.0 still being supported.
closesodoo/odoo#81721
X-original-commit: 376ccf0944dae1bc53ae9c5385977c4e6b23e083
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before, the 'success' key was removed from the results
of the invoice processing and as such the invoice
was never put as successfully sent, but you sent it
again and again.
closesodoo/odoo#81911
X-original-commit: 853ff30b76a56bcb9af88256aac3a3ceb93bf562
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
In urllib3 1.25, an _is_key_file_encrypted method was added
where urllib3 checks if the keyfile is encrypted or not, but
urllib3 uses filenames, while we want to use the contents of cert.
So, in our case, this gave a traceback because it could not open
the file.
The final simple solution for now is to keep keyfile empty as
we store our info in certfile anyways already.
X-original-commit: f908171f91107a4972b29e575bb722c0dabf4ee3
Part-of: odoo/odoo#81911
Core client remains incompatible with CSP, however it can't hurt to
CSP the sub-resources.
Current scheme is simplistic, however if useful of necessary it could
be made more flexible e.g. there could be a map of mimetypes to CSP
configuration, that sort of things.
The origin parameter must be an absolute link (starting with a /)
To be consistent and always have a leading slash (and avoid relative
links if the developer forgot to add a leading slash)
All textual content generated by opening the tag must be flushed before
inserting the default content
closesodoo/odoo#81700
X-original-commit: effeba10787388ee0a3d153c984fab5731fc9b1a
Signed-off-by: Thibault Francois <tfr@odoo.com>
Signed-off-by: Olivier Dony <odo@odoo.com>
To reproduce an issue:
Open Recruitment Form from Surveys app. Share it with a recipient.
For example with Azure Interior.
Current behavior:
2 registrations are created, including an empty one.
Expected behavior:
Only 1 registration (for Azure Interior) should be created.
Task-2694600
Partial rewrite of odoo/odoo#81851closesodoo/odoo#81903
X-original-commit: a0a626253b62f01d6bbfe56b98fdedb2317b9598
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
2021-12-25 02:26:44 +00:00
Laurent Stukkens (LTU)andXavier BOL (xbo) <xbo@odoo.com>, Nicolas Seinlet <nse@odoo.com>
This commit adds an index on the user_id field of account.analytic.account
task-2700429
closesodoo/odoo#81907
X-original-commit: 9b7ad00143145030ca67d8a7bfbe44b700cd1573
Related: odoo/enterprise#23100
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Co-authored-by: Xavier BOL (xbo) <xbo@odoo.com>, Nicolas Seinlet <nse@odoo.com>
Currently when converting leads we may end up with False being compared to
a void partner recordset. Due to the use of != this leads to unnecessary
update of leads when no partner is involved in lead convert.
By comparing recordsets everytime we save queries and performance each
time a convert on a lead without customer is done. This leads to about
saving 150 queries in heavy duty tests.
Task-2722512 (Lead: performance in convert without customer)
Task-2722513 (Lead: performance master task)
closesodoo/odoo#81028
Related: odoo/enterprise#23094
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
When creating an opportunity, set the language of the Lead/Opportunity
to the partner's language if it is set instead of leaving it blank.
Also update tests to correctly test lang propagation.
Update event_crm so that lang of lead from registration is directly set
to False when there is no partner. Indeed we have no clue which lang we
should set and we can skip the field computation that otherwise triggers
some additional queries.
Task-2709436
Part-of: odoo/odoo#81028
The creation of recordset was done by class method _browse() instead of
a regular call to the model's class. As we removed the old usage of
method __init__(), we can now reuse it with a normal usage. After this
commit, we can create a recordset by simply calling its class:
registry['model_name'](env, ids, prefetch_ids)
closesodoo/odoo#79563
Signed-off-by: Raphael Collet <rco@odoo.com>
- Remove unused imports `AsIs` and `Collector`
- Remove unused logger _schema
- Remove unused function same_name
- Remove unused attribute `_needaction`
- Remove backward compatibility of `__new__` and `__init__`
- Remove backward compatibility of `__export_rows`
Also:
- remove deprecated warning in api.py
- remove the `__init__` from `ir.ui.menu`, it was useless
because the cleaning of cache (`clear_caches`) is global (a call of
`clear_caches` clean all cache method with a ormcache decoration)
Part-of: odoo/odoo#79563
The method BaseModel.update does not batch records for no reason. This
method is used in `_onchange_eval` and in few onchange in Odoo.
In _modified_triggers() avoid a useless record union.
Part-of: odoo/odoo#79563
The method refresh() is a duplicate of method invalidate_cache() and is
deprecated since version 8.0, but without any warning. Add this warning
to be able to completely remove it in the next major version.
Part-of: odoo/odoo#79563
When printing a ticket, if some lines mix RTL and LTR words, the
rendering won't be correct
To reproduce the issue:
(Need l10n_sa. Use demo data)
1. Switch the company: SA Company
2. Create a point of sale POS
- Setup a direct device to print the tickets
3. Start POS
4. Process an order and print the ticket
Error: On the printed ticket (not the displayed one, which is correct),
some Arabic words overlap (see for instance the "Served by").
When printed the ticket, the latter is converted into an image thanks to
`html2canvas`. However, we need to add a space to separate LTR and RTL
words, otherwise the rendering won't be done properly. A similar issue
can be observed if the user language is AR: some other rendering issues
can be noticed on the ticket.
OPW-2704550
closesodoo/odoo#81899
X-original-commit: 86a20f7ef1b93eb099110feec5bca05b3a8d9a39
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
There is an issue when exporting pdf using edi documents created before
the PDF/A commit. With the subtype now included, the system would try
to use the subtype given by the ir.attachment which would not be formated
as expected by the pdf file format.
The attachment may get neutered by the ORM, so we may have to force
the mimetype when embedding it.
This fix in two parts will allow to force a subtype when adding an
attachment into a pdf, as well as parse the subtype of ir.attachment
to give them the right format.
xxx/xxx should become /xxx#2Fxxx
opw-2714040
closesodoo/odoo#81898
X-original-commit: 880d7a1c8474a3bee4fd05474788fbd4a63f4ae7
Signed-off-by: Laurent Smet <las@odoo.com>
As JS is not taking the properties in the order they are written,
the order in the rendering was always following the property name
sorting order (=id).
Previous to this commit:
- The companies were ordered by their id in the company switcher as
JS is not tacking the object properties order into account.
After this commit:
- The companies will be sorted by their sequence prior to be used in the
rendering.
task-2722235
closesodoo/odoo#81893
X-original-commit: 39c678a1ccb50d3a1871a4049a8df26427b27a3c
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
When sending a survey invite, applicant_id was populated with whatever
active_id was available, regardless of the origin model.
This was preventing users without Recruitment access rights from sending
surveys.
closesodoo/odoo#81867
Taskid: 2721987
X-original-commit: ac811fc591eb89c8d9dc472c10abb2020e5fc14e
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Bug
===
Since 2d359b909b we moved the mailing
list feature of the <mail.channel> in a different model, <mail.group>.
During this split, some SMTP headers have been forgotten.
Task-2721009
closesodoo/odoo#81887
X-original-commit: daf9c0300fb042891c019e4f2a8c5395de388e1c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes an issue where the trash icon was not properly
shown in the dropdown when adding more custom filters.
A test has been written to verify if the download button is
present in the dropdown.
task-2716032
closesodoo/odoo#81871
X-original-commit: af566b663f42479ade2d4b4b01d052215be85c1e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
In preparation for using OWL v2 in discuss code.
(shouldUpdateBasedOnProps will be removed)
Solution consists of introducing MobileMessagingNavbarView model.
Task-2695743
closesodoo/odoo#80617
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Romain Derie