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>
Added CoA and account groups for Kenya.
Added taxes for Kenya
task-2809108
closesodoo/odoo#91396
X-original-commit: ac95f9f961405ed6f6b24f08a8aab05a6561e410
Related: odoo/enterprise#27344
Signed-off-by: Florian Gilbert <flg@odoo.com>
First thing is that when you send an invoice to PA in test/production,
it should be considered as sent after the xml is generated as we do not
have the functionality to send sign invoices yet.
We added a test for posting the invoice when the invoice partner has a
l10n_it_pa_index (and it is of length 6).
Alos, when the proxy user is a 'demo' user, creates a
traceback. The solution is to only add the demo response to those that
would have been sent to the iap server otherwise.
We also avoid doing a call to the IAP server if there are no invoices to be
sent (e.g. because they all go to the PA)
opw-2807213
closesodoo/odoo#91419
X-original-commit: 2221f0145607e4cd0880e7435b637f620d15cecf
Signed-off-by: William André (wan) <wan@odoo.com>
This is actually checking if for each tax of each line of invoice in the move, there exist a tax entry.
This will prevent the users from accidentally or dully erasing tax lines which includes 0% taxes.
If the users delete the line containing tax, it will be added again the same way as the counterpart line
for an invoice line is being added.
Also, fixes the following:
Recalculating all invoices if a single invoice in a batch has a line with `recompute_tax_line` set should not be allowed.
Deleting a tax account entry of a posted move should not be allowed.
task ID:2834679
closes odoo/odoo#91414
Pr: #90834
X-original-commit: 5f39f8c1533502be52ea9d3ef114430b5b8cd9a6
Signed-off-by: William André (wan) <wan@odoo.com>
purpose of the task is to improve the usability of the base,
base_geolocalize, project and web
task-2764760
closesodoo/odoo#85295
Related: odoo/enterprise#24706
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The current problem is that the codice fiscale field is validated using
a regex that matches an alphanumeric code of 16 digits (that causes no
problems) and both a simple numeric code (of 11 digits) and an
alphanumeric code (of 13 digits, starting with the country code 'IT')
for businesses. The problem is that the systems that make use of the
codice fiscale code tend to utilise the former (i.e. the 11 digit code,
without the 'IT' prefix).
The filename for the EDI comprises a country code, the codice fiscale of
the company and a progressive number. When the codice fiscale is
completed as being eg. 'IT00465840031', the country code + codice
fiscale will be 'ITIT00465840031', which will be rejected by the edi
system (a single country code is expected).
This commit removes the 'IT' in the xml by utilising a function on the
template _l10n_it_normalize_codice_fiscale from the res.partner model.
related ticket-id: 2845341
closesodoo/odoo#91370
X-original-commit: 39dcee1cc1ef1ed4c4a85494b689f4f604e32de6
Signed-off-by: Josse Colpaert <jco@odoo.com>
*: account_payment, sale
This doesn't change anything from a technical point of view, but it
helps to consistently assess whether a method is attached to a route or
not, only by looking at the class' skeleton.
closesodoo/odoo#91359
X-original-commit: 93de42458ed0a7df20a7bc2f2c2b106386293c78
Related: odoo/enterprise#27330
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This typo crashed the code because the component expect
receiving the view record as prop.
closesodoo/odoo#91358
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
- What is broken:
The /article command of the editor when editing a page on `website` has a
traceback and the dialog does not open.
- The fix:
Add a xmlDependency to the KnowledgeArticleLinkModal so that the modal can be
used in website to select the desired article when using the /article command.
Task-2674460
closesodoo/odoo#91343
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>
*: hr, test_mail.
This PR prepares the ground for the one introducing the new environment in the
discuss app. Indeed, the createWebClient helper will be used instead of createView/Widget
thus the returned value won't be a Widget anymore but a DOM element. This change impacts
they way the tests were written: JQuery functions have to be transformed to native JavaScript
ones. In order to reduce the noise in the main PR, those changes are done now.
task-2582313
closesodoo/odoo#91290
Related: odoo/enterprise#27313
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: im_livechat, website_livechat.
In order to reduce the noise in the PR introducing the new environment in
the discuss app, calls to widget.call, env.bus_service.call during tests
have been replaced by a mocked implementation of _sendone/_sendmany. Moreover,
this approach will allow us to mock the longpolling during tests, resulting in
a more realistic behavior.
task-2582313
closesodoo/odoo#90724
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Aurélien Warnon