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>
If a default template is specified in a given database (it is the case by default
on runbot databases because of sale_quotation_builder), the webclient will
try to fetch its display_name (through a name_get rpc).
As this happens even if the default_sale_order_template_id field is hidden
in the view, administrators without sales rights were not able to open the settings,
because they didn't have read rights on sale.order.template model.
This commit makes sure that settings users are able to open the settings
independently of their level of rights for the Sales scope (salesman/sales manager).
Fixes#84597closesodoo/odoo#91380
X-original-commit: 74857e31bd5ecc329cb4f07b786e199e01da044f
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
PURPOSE
With this commit, when trying to schedule a mailing with a
past schedule_date one will be asked a new date.
LINKS
Task-2833321
closesodoo/odoo#90891
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Payment's partner_bank_id cannot be modified because the field is in
readonly
Steps to reproduce:
1. Install Invoicing
2. Go to Invoicing > Vendors > Payments and create a new payment
3. Specify a vendor, edit this vendor and add two bank accounts (in the
Invoicing tab) then save
4. The field 'Vendor Bank Account' is populated with one of the bank
accounts
5. Save the payment then edit it again
6. Change the 'Vendor Bank Account' and save
7. Refresh the page
8. The 'Vendor Bank Account' hasn't changed
Solution:
Add a condition to the readonly so that it only applies when the field
'Company Bank Account' is displayed
opw-2826507
closesodoo/odoo#91406
X-original-commit: 47b69d6cbf1bf9c9512a4b46a223e3b9f3c89e06
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
When clicking order now on a replenishment line (orderpoint) for a manufacture or WH resupply route, it will sometimes show a notification for a purchase order that was created earlier instead of the correct one.
closesodoo/odoo#91404
X-original-commit: 9ca9bcc51fa289ddb0548f81a795755d196e31ca
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to follow
- Go to project
- Click on the 3 littles dots on a card
- Go to Burndown Chart
- Add a custom filter on the date_group_by field
-> this.fields[condition.field].selection[0]
Cause of the issue
The date_group_by field selection should be declared as a list, not a
tuple
opw-2819936
closesodoo/odoo#91397
X-original-commit: e3254a882199f229e4a8b4f38ce7f7529fd8da46
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Before this commit, some dialog's footer buttons were glued to each
other which impacted their readability and usability.
This commit fixes it by properly applying the existing `gap` CSS rule
which defined the spacing between the buttons, and this independently of
the structure of the footer.
Indeed, due to historical reasons, the `.modal-footer` may contain
drastically different structures depending of the kind of modal.
A non-exhaustive list of encountered structures:
- `.modal-footer > button`
- `.modal-footer > div > footer > button`
- `.modal-footer > div > button`
Note: some existing rules already illustrate that in `modal.scss`.
task-2792884
closesodoo/odoo#91371
X-original-commit: d15bfc785d392a7dffadf9489d1d21f449d42ca4
Related: odoo/enterprise#27337
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Purpose
=======
Change all masculine nouns in Odoo's code to neutral nouns (when
possible), making sure that demo data is correctly handled. This is
particularly important since our code is open source, and nowadays lots
of machine learning models are trained on open source repositories.
With this small change we contribute to training more "fair" models, and
teaching models that "employee" or "user" != "he".
This also affects some text visible by the user, hence making it more
inclusive for Odoo users.
Task-2853046
closesodoo/odoo#91292
Related: odoo/enterprise#27302
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Prior to this commit:
- If the color attribute is set on a field on which the user might
not have access to the model / record, a traceback is returned. However,
in the case of a M2O, the name_get would be returned, so its is
a pity that the color raise an access error.
After this commit:
- A search_read is made instead of a read, which returns nothing if
the user does not have access to the model / record and does not raise
a traceback.
closesodoo/odoo#91147
X-original-commit: 3e8744418d629a62e9eacd16dfa4721921e02453
Related: odoo/enterprise#27318
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
How to reproduce the bug ?
- install the CRM and sales modules
- remove the user from the all the sales security group
- go back to the dashboard and click on settings
What is the bug ?
The res.config.settings model of the CRM module has a field referencing
the crm.lead.scoring.frequency model. This model can only be accessed by
the members of the sale security groups. If an admin is not part of the
sales group, he will get an error when he wants to access the settings
while he will not see the sales or the crm settings tab.
opw-2755177
closesodoo/odoo#91405
X-original-commit: 5f2d6dfac018339283971eadc2a3bbadc857ae35
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Minet Adrien (admi) <admi@odoo.com>
There are several instances in TestAccrualAllocations where freezetime is used on a dynamic date.
This fix freezes the time to an iconic date.
task-2853089
closesodoo/odoo#91316
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Brieuc-brd