Issue:
When receiving a mail with a facturx XML file as attachment,
the datas in the XML files are not parsed.
Cause:
For security reason, if a mail attachment is a XML file, it will
be saved as plain text and therefore not be parsed.
Solution:
If attachment mimetype is `plain/text` and content starts with
`<?xml`, consider attachment as XML for the parsing.
opw-2655445
closesodoo/odoo#91609
X-original-commit: c402815652cedae1c0934edeefac7cd547b12d0a
Signed-off-by: William André (wan) <wan@odoo.com>
When we receive status changes of sent invoices, we send an
ack message to the proxy afterwards to indicate we received it
correctly.
However, as awaiting_outcome is the initial state for which no
message about the invoice state was received from the gov, we do
not need to ack it as it just says "we are still waiting for the
first msg from the gov"
In a scenario:
Normal flow:
- Odoo instance sends invoice to proxy, proxy to gov, which sends back transaction_id
- On the proxy, the state of the transaction_id is awaiting_outcome
- The gov sends a message back to the proxy that the invoice is approved (directly to the server), so the state becomes "approved"
- The odoo instance asks for the status, receives the "approved" message and then tells the proxy he received it
- The proxy deletes the "approved" message
What we want to avoid:
- Odoo instance sends the invoice
- Proxy: awaiting_outcome
- Odoo instance checks the status and the server returns "awaiting_outcome"
- The gov sends a new message
- The Odoo instance acks and says he received the msg (there is actually no message associated)
- The new message from the government gets deleted.
closesodoo/odoo#91608
X-original-commit: 7d992af9561c499ef1912453f3b697bad18e441f
Signed-off-by: William André (wan) <wan@odoo.com>
This commit fixes the Signup link under the quiz validation.
widget.url is not defined in widget.
Now we use the redirectUrl from the widget as redirect after the signup.
It has been detected by a number of hit on /web/undefined
closesodoo/odoo#91575
X-original-commit: 8d9f22dbe109015bf62e8b563dffa30f45773d26
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Lines cannot be deleted if the order is confirmed. However, notes/sections lines
still might be changed. So, let delete such lines too.
STEPS:
1. Create SO, add product and add note
2. Confirm SO
3. Remove note
---
opw-2852676
closesodoo/odoo#91552
X-original-commit: eaf34c85ae3db1c85a443ea57ee096e64d0bfbc5
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Since 15.2, when creating an invoice containing both a recipient address and an invoice address, the addresses would both appear on the left, one after the other.
This made reading difficult and the invoice unclear.
Furthermore, the company address wasn't present by default on the invoice : it was only there if a layout had previously been selected.
This PR:
- reverts the behaviour of the company address, i.e. it appears even if no layout is (yet) selected ;
- aligns the delivery and the recipient address on each side of the page when necessary, while not changing the outcome if a single address is given.
Also displays a "title" above the addresses when necessary to make things clearer.
task-2809240
related : https://github.com/odoo/enterprise/pull/27240closesodoo/odoo#91487
X-original-commit: 1e745256fabbec4d6979180d8f792c99be463509
Related: odoo/enterprise#27383
Signed-off-by: Florian Gilbert <flg@odoo.com>
Task ID: 2717840
Currently:
- Generic_coa has country_id US, which is not valid for non-supported localizations. This creates a bug as the country on taxes and account_fiscal_country_id becomes different.
- Users who only have Invoicing installed can't change the fiscal country setting as it's only available in Accounting.
Desired:
- Set account_fiscal_country_id the same as country_id
- Remove base.us from l10n_generic_coa
- Adjust the error message to make the issue more clear for users
- Allow changing fiscal country in Invoicing
closesodoo/odoo#91363
Related: odoo/enterprise#27332
Related: odoo/upgrade#3264
Signed-off-by: Laurent Smet <las@odoo.com>
This commit shows the sum of field 'recurring_revenue_monthly' on
leads' kanban progressbar next to the sum of 'expected_revenue',
if the recurring revenu is enabled for logged in user.
taskID-2414576
closesodoo/odoo#66237
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
How to reproduce the bug ?
- install the inventory app
- open the app and try to import a file where at least one cell has a
wrong value
What is the bug ?
When you try to import a file in the inventory app where at least one
cell has a wrong value, the file won't be imported. In addition to that,
you will get an error saying that one python module is missing while
this might not be the case.
opw-2715625
closesodoo/odoo#91482
X-original-commit: cafd8699ff8ec8eb93aa283a4cac57317ce40708
Signed-off-by: Adrien Minet <admi@odoo.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Simon Goffin <sig@odoo.com>
Before this commit, when searching something via the searchbar snippet
when it is in a mega menu, the dropdown that appears could not overflow
the mega menu dropdown and thus was mostly hidden.
opw-2779432
closesodoo/odoo#91512
X-original-commit: 4805b31e160493715f3c0647b6e8f2d5f6d50c0b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When the admin opens an email, they might get an error message if they
can not access one of the attachment of the email or because of the ACL on
mail message.
In this merge we avoid that issue by fetching only accessible attachments
and allow checking related email_from, reply-to and subject as sudo.
Task-2464212
closesodoo/odoo#78734
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Bug
===
When the admin open an email, he might get an error message if he can
not access the mail message.
Technical
=========
To allow to bypass mail message ACl without adding extra SQL queries, we
need to overwrite "_add_inherited_fields".
This trick add a related_sudo on the inherits fields, it can't be done with
>>> subject = fields.Char(related='mail_message_id.subject', related_sudo=True)
because the field of <mail.message> will be fetched two times (one time before of
the inherits, and a second time because of the related), and so it will add extra
SQL queries.
Task-2464212
Part-of: odoo/odoo#78734
Bug
===
When the admin open an email, he might get an error message if he can
not access one of the attachment of the email.
Now the admin is able to view / edit the attachments he has access to.
Task-2464212
Part-of: odoo/odoo#78734
To reproduce
============
- Create a new Survey.
- Add questions under at least two sections.
- In Options, ensure that each section is displayed on its own page.
- Click "Share" and open the share link.
- Partially complete the survey and close the window before submitting.
- From the survey click "See Results". Then choose a response to a question from the partially completed answer.
- A traceback raised
Purpose
=======
On this condition :
https://github.com/odoo/odoo/blob/3602fdfc0ce8ed76a530c8c3cc1d49eecf9d250c/addons/survey/views/survey_templates.xml#L27
we check if we have to display the progression or not, in case of consulting results it doesn't make sense displaying it.
that's mean the check made in `t-if` was not enough in this case and a condition is missing.
Specification
=============
to solve the issue the condition `not survey_form_readonly` was added
opw-2821478
closesodoo/odoo#91513
X-original-commit: 98e3dcea9f0f86a4879999f73019c11a880f6a77
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
When fetching the views of a one2many/many2many fields
in a form view, do not propagate the context keys
`form_view_ref`, `tree_view_ref`, ...
It was supposed to be already handled,
but the keys were not removed when the arg `view_id`
is passed to `_get_view`.
closesodoo/odoo#91489
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
In some cases, the runbot running the tour was clicking on the
"restart conversation" button before we had the chance to register the click
event on it.
This small commit adds a "ready" class on the button when we have correctly
registered the click event, and makes the tour step wait for that class before
clicking to restart.
closesodoo/odoo#91505
X-original-commit: 623fdb15ce9a6f3f586254dca549a72869336729
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
I apparently missed this case in #88871: Google's legacy
flow (response_type=token) explicitly rejects a `nonce` parameter
being passed in the authentication request. The nonce parameter is
only accepted for an OIDC-conformant implicit flow request (aka
`response_type=token id_token`).
The specific endpoint doesn't seem to have any bearing on this, v1 and
v2 authentication endpoints result in the same behavior.
Drawback: Okta isn't supported anymore, as it requires the nonce, no
if, no but, even on "legacy" auth requests, possibly others. However
since these already weren't supported that's considered less of an
issue than possibly breaking compatibility with existing IDP.
Rejected alternative: adding `id_token` to the `response_type` to come
closer to OIDC-conformant request, however that was considered too
risky: Odoo clients could be using legacy IDP which also reject the
nonce parameter but don't have a magic "OIDC conformant" trigger.
closesodoo/odoo#91500
X-original-commit: 1fd738d9826f9bdfe8deddd5ef81dcb9757e8988
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Olivier Dony <odo@odoo.com>
This PR prepares the ground for the one introducing the new environment in the discuss
app. Indeed, the discuss widget will be removed since it was used as an action. This widget
basically handle two things: rainbowman on empty inbox/push state. This second part focuses
on the push state aspect.
task-2582313
closesodoo/odoo#91450
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit will correct the precision_rounding parameter in the float_compare call to use the current move's product. Previously, this was using the product_id variable from a previous for loop.
An issue is caused when a transfer is created from `mts_else_mto` procure methods in stock.rule records. When the '_adjust_procure_method' hits a rule with this procure method, it reaches the 'mtso_moves' for loop. The needed quantity and forecasted quantity will be compared to decide whether a stock.move record is needed to fulfill the needed amount.
The problem is that the 'float_compare' method is using 'product_id' to set its precision_rounding method. The 'product_id' variable is only accessed in the prior for-loop and will always reference the final product iterated. As a result, any case where there are product quantities smaller than the final product's UoM, it is skipped.
opw-2820401
closesodoo/odoo#91361
X-original-commit: 892232b5aef42dd2706cb9d1d027b1c463ca50dd
Signed-off-by: Arnold Moyaux <arm@odoo.com>
As result of [1], control panel's search menu-items were highlighted
correctly on ':hover', but not using a keyboard.
This commit assigns the default <Dropdown> 'focus' class on both
circumstances.
[1] https://github.com/odoo/odoo/pull/87448
task#2852217
closesodoo/odoo#91206
Related: odoo/enterprise#27355
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
With this commit, the picture used will be the employee one if there's no user attached to it. If there's an user and this one does not have a picture, we'll take the employee picture.
closesodoo/odoo#83893
Task-id: 2719656
Signed-off-by: Masereel Pierre <pim@odoo.com>
Functions like `_get_price_total_and_subtotal` should be able to handle false-y values like 0 or empty recordset,
currently invoking them with these values (e.g. discount=0) leads to use record values instead of given values.
closesodoo/odoo#91456
X-original-commit: 7830655e75ec53c6fa48d916019d325f0e6c8a6b
Signed-off-by: William André (wan) <wan@odoo.com>
With this commit the user can search for currency name, code, symbol or even subunit name
task ID:2846565
Pr: #90913
Signed-off-by: William André (wan) <wan@odoo.com>
With new key of `allocation_validation_type` field, this code is no
longer relevant
closesodoo/odoo#91464
X-original-commit: 89faeeab7efe3bcc629bd4d48f44eb9a55bee9ec
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Currently traceback occurs if allocation leave is approved.
It has been fixed.
closesodoo/odoo#91402
X-original-commit: 7699f6b9105c2d810b5ddc0446943670c5cbbd22
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This PR prepares the ground for the one introducing the new environment in the discuss
app. Indeed, the discuss widget will be removed since it was used as an action. This widget
basically handle two things: rainbowman on empty inbox/push state. This first part focuses on
moving the rainbow man logic to the discussView model.
task-2582313
closesodoo/odoo#91365
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
On a traceability report, if a user clicks on a lot and prints the new
report, an erorr will be displayed
To reproduce the issue:
(Need mrp)
1. Create two storable and tracked-by-lot products P_compo, P_finished
2. Update quantity of P_compo:
- 1 x P_compo with lot L_compo
3. Create a bill of materials
- Product: P_finished
- Components
- 1 x P_compo
4. Produce 1 x P_finished (lot L_finished)
5. Inventory > Products > Lots/Serial Numbers, open L_finished
6. Click on Traceability, unfold the line and click on L_compo
7. Print the report
Error: an Odoo Server Error is displayed (RPC_ERROR)
Since [1], the route has changed
[1] e2f59a6dd1
OPW-2773967
closesodoo/odoo#91453
X-original-commit: c0aefc788059499a745fc1787a253b3367dce8d5
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Current behavior:
In PoS restaurant cashier were not saved correctly in db if you
switched table before making the payment of the order.
Steps to reproduce:
- Install PoS
- Activate restaurant on one of your PoS
- Activate Authorized employee
- Start a PoS session, and select a cashier
- Create an order on a table
- Leave the table and comeback to it
- Make the payment for the order
- Go in the PoS orders, the cashier wasn't saved
opw-2794574
closesodoo/odoo#91447
X-original-commit: 2c6ea058f9f8cfaf75529ff4028913a59f021ab8
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
The first date should be the date of the record creation instead of the
time the model was initialized.
closesodoo/odoo#91372
X-original-commit: 2635b29193ba16d85f62aabd8bddd7d7692007f0
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Before this commit, the overlay with status icons of the participant
card was at the border of the whole card, which made it difficult to
see in some situations, like when focusing on one participant.
This commit places the overlay over the main frame of the card.
part of task-2692836
closesodoo/odoo#91297
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Cleaning of the principal methods used in the pos_restaurant flow. This make the code a lot more readable and maintainable as we strive for the single responsibility principle.
A few notable changes:
- [REF] `point_of_sale.assets` in `pos_restaurant` now uses glob syntax (`**`) for the js files, no need to add them in the manifest anymore.
- [MOV] Moved some methods to `pos_restaurant` (because it was only used there) from the `point_of_sale`
- [REF] Only the created, removed and updated orders of a table are being sent to the server once we reach the Floor Screen. Before, all the orders of a table were being sent to the server as the newest state. This led to some synchronization problem when two users wanted to modify each a different order of the same table, the user leaving the table last had **all** his orders states (even the ones he didn't modify) pushed to the server.
- [IMP] After a table transfer while being in offline mode, the transferred order is saved locally (if not yet synchronized) and going back to the previous table after getting the connection back will no longer show the transferred order after the orders fetching from the server.
- [FIX] When an order is selected (normal Point of Sale and in a table in `pos_restaurant`), the selected order is not changed in the Ticket Screen when deleting an order unless the deleted order is the current selected order.
- [FIX] Same as above but while settling all the tips from the `Ticket Screen`
- [FIX] Errors are now properly handled in the `Floor Screen` depending on the context.
- [REF] Kitchen order printing flow has been revamped and improved. This also fixes a bug where we would print a cancelled receipt changes for a skipped order line when adding a product which was already printed before (add 1 product => print => add same product + skip => print would give a cancelled changes for this order line).
closesodoo/odoo#85956
Related: odoo/enterprise#25051
Related: odoo/upgrade#3375
Signed-off-by: Masereel Pierre <pim@odoo.com>
Configuring the email_to field on the contact us page was not working
anymore. The email was always sent to the company email whatever the
user chooses in edit mode. This was due to [1] which gave the priority
to the data-for and prefill system over default values. While this makes
sense in general (e.g. if the URL on the contact us page contains
?name=John, then the form is prefill with "John" whatever the value that
is set as default), it does not make sense for the email_to field which
is always prefilled with the company email.
The data-for/prefill system priority probably has to be reviewed in the
future. Meanwhile, this commit will make the email_to field as an
exception for this system and only use the data-for value if nothing
has been configured by the user.
This commit also handles another case. Indeed "if nothing has been
configured by the users" is currently kinda broken as just clicking on
the form and saving will force the value "info@yourcompany.example.com"
as the email_to value... thus making the form use it instead of the
company email. We will make that as an exception of the exception: use
the data-for value (company email) if what was configured by the user is
the dummy default value "info@yourcompany.example.com".
A test for each of those two exceptions has been added (only the first
test breaks before this commit as [1] made the second test pass by
chance).
[1]: https://github.com/odoo/odoo/commit/7b23d3aacd22f87cb0c22ecd0478eba4a17b4bf3
opw-2842211
Original idea for the first exception:
closesodoo/odoo#91407
X-original-commit: a08574a04ff2ce8ea2d6fd2b79f56cc57bba953b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Ivan Yelizariev <iel@odoo.com>
Nasreddin Boulif (bon)