Before this commit, new messages from odoobot were never opening
a chat window automatically.
This is desirable only during the onboarding process of the user,
when first logging-in, as to not bully the new user. It is not
intended to prevent all new messages from odoobot.
This commit fixes the issue by only preventing auto-opening of
chat window of odoobot for the 1st step of the onboarding process.
closesodoo/odoo#132689
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
The report "Manufacturing Orders" is just the graph/pivot view of MO,
most of the infomation can be found on a more accurate report
"Production Analysis".
In this commit, we removed "Manufacturing Orders" from the report view.
Users can still access it from Operations -> Manfacturing Orders ->
graph/pivot view.
Task-2695732
closesodoo/odoo#130342
Related: odoo/enterprise#44912
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Currently on stock moves, product_uom_qty indicates the demand qty
before the move is done and it indicates the acutual done qty when
the move is done.
As a result, when validate a stock move with qty_done !=
product_uom_qty, a new move is always created for the difference.
And the product_uom_qty of the original move will be changed to match
qty_done.
In this commit, we change to that product_uom_qty will always indicate
the demand qty, and qty_done will always indicate actually done
quantity.
To do that, when underconsumption, we won't split the move when no
backorder. and when overconsumption, we will always merge the extra move
back to the original move.
Task-2695732
Part-of: odoo/odoo#130342
Issue:
-------------------
When creating invoices for two sales orders with the same customer the field amount_to_invoice is wrongly calculated and it shows a negative value when it should be zero
Steps to reproduce:
-------------------
1. Go to Sales -> sale orders
2. Create two sale orders with the same customer
3. Confirm the SO’s and delivery the items
4. Create the invoices for both SO’s
5. The field amount_to_invoice is negative
Cause:
-------------------
The method _compute_amount_to_invoice considers the value of all sale orders without any filter, but in this case we have two different sale orders and we only have to consider the value for the respective SO.
OPW-3437237
closesodoo/odoo#132859
X-original-commit: e2ec9e6c86949f5781d03a7dbb1065ef8af3196a
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Since the fix of the QR bill headers (see task-3241502, PR:https://github.com/odoo/odoo/pull/130478), the print in batch functionality raises a stack trace.
This is because the render_qweb_pdf_prepare_streams method in base/ir_actions_report.py wasn't meant to handle multiple pages report without specific titles in its HTML structure, which is here the case since the QR bill fixing merges the top of one page with the end of another, therefore creating a peculiar structure.
In those cases we can consider that if each non-generated stream corresponds exactly to one page in the PDF reader, this is a simple batch printing case and we can just handle each page separately.
task-3241502
closesodoo/odoo#132816
X-original-commit: 84fdd2eb11e42f0422dd62961aea7fe4e6f52da3
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Camille Spiritus (casp) <casp@odoo.com>
*: mail, website_livechat.
This PR fixes two issues with the live chat requests when initiated by the
operator:
- Thread name should not include "website" since [1]
- Welcome message should not be shown when the operator is the one who
initiated the chat
[1]: https://github.com/odoo/odoo/pull/125931closesodoo/odoo#132815
X-original-commit: 38a6658beec8bd4423ee8b4ac16f2592b9fb36ff
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Steps:
- Installed hr_attendance app
- Open attendance app and go to report menu
- Click on any cell
Issue-
When we click on the graph or pivot cell of the attendance report, the
attendance report tree opens instead of the attendance tree.
Why issue occurred?
In this commit the openView function has moved from (Graph/Pivot) Controller to
Renderer and in hr_attendance openView is in Controller so the issue has arisen.
Commit-https://github.com/odoo/odoo/commit/c8ca9da7bcee2c122a9d6cf8cda89f02823ba42d#diff-4e5bfd019e8d595efdf999a6b56fcb45a3127bb8bd7bb960161710bcfcd83687
task-3420173
closesodoo/odoo#132805
X-original-commit: 14504c0f4576ae76b095d3ea5f00f72c077f532f
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Prakash Prajapati (ppr) <ppr@odoo.com>
This commit does the following:
- remove the unused o-swap() SCSS function
- remove the unused mixin o-kanban-header-title and its related variable
- inline kanban specific mixins used only once (o-kanban-tag-color,
o-kanban-dropdown, o-kanban-dropdown-open)
task-3439226
Part-of: odoo/odoo#132787
This file is only loaded in the backend bundle and overrides the
Bootstrap Tooltip's styling which the backend doesn't use anymore.
task-3439226
Part-of: odoo/odoo#132787
After convertion of the ImageCrop widget to an Owl component [1], the call
to `this.displayNotification` no longer applies. In fact, it produces a
traceback when trying to crop an image that cannot be cropped
(base64-encoded image not yet converted to an attachment, for example).
This commit replaces such call for the more suitable notification
service's `add` method.
task-3471481
[1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997closesodoo/odoo#132726
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
before this commit, the added user error and validation
error is not translatable to end user language.
after this commit, user error and validation error will
be show in users language
closesodoo/odoo#132637
X-original-commit: e2e580a0b83356dc32bc31bafaf1a3d03b47e266
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
In order to allow all communication to be sent in
a chosen language, a 'lang' field is added on the
event.event model. If set (amongst the installed languages)
this language will be used to translate email templates
instead of the partner's one (which is still the default one)
The field is added on the event form view.
Task-3357099
closesodoo/odoo#127540
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Purpose
=======
Currently the user interface let you specify several correct answers
per quiz question. But when you save the course, you get a notification
error. As those are simple quizzes, it might be interesting to simply
allow multiple answers.
Specifications
==============
Allow questions with multiple correct answers.
Back-end views: improve feedback when user forget to set at least one correct
answer and one incorrect answer per question.
Task-3366803
closesodoo/odoo#127065
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Have a grouped kanban view with sample data and existing groups,
and the quick create feature enabled (e.g. CRM pipeline). Click on
"New", or on the "+" of a column. Before this commit, all columns
displayed the "Load More" button, with the count of sample records
that had been generated for that column, even though the columns
were empty. After this commit, no "Load more" button is displayed,
as expected.
closesodoo/odoo#132802
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Have an editable list view with sample data (sample="1" and no
record). Before this commit, there was a flickering when the user
clicked on "New" to add a record. Indeed, the list was first
re-rendered without the sample mode (i.e. without the opacity style
and no content helper), but still with the sample records. With
this commit, we wait for the reload to be done before leaving the
sample mode, s.t. when the list is re-rendered, we don't have
sample records anymore.
Part-of: odoo/odoo#132802
Before this commit, the current user was cleared after every
test. This is an issue since we can still interract with the
page after the test is done when in debug mode. This commit
fixes the issue by clearing the current user at the beginning
of each test instead of the end.
closesodoo/odoo#132801
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
If model A has a selection field, and is inherited by 2 modules
B and C, B adds selection values to the field, and C inherits model
A under a different module and model names.
Based on the order of installation of B and C, we may end up with
different xmlids.
If B is installed before C, then B will add xmlids for the new
selection values added for model C. But if C is installed before
B, then C will have the selection values from B without xmlids.
The change here ensures that the selection values introduced by B
will always have correct xmlids.
closesodoo/odoo#132765
X-original-commit: c673d9db40cb91d4eb12cb787ff114068a924caa
Signed-off-by: Raphael Collet <rco@odoo.com>
If we try to register payments for multiple expenses with multiple bank accounts from the expenses app, there is a traceback regarding the bank ids, as a singleton value was expected. We can do the same process from the vendor bills and the payment will be registered fine.
1. Create two expenses against two employees having different bank accounts.
2. Approve and post both of them.
3. In the 'To Pay' expense list, select the both expense reports and click on register payment.
Current Behaviour:
A traceback is thrown that a singleton value was expected. This is because there were multiple bank accounts against that payment.
Expected Behaviour:
The payment should be registered without any problem.
OPW-3272500
closesodoo/odoo#132774
X-original-commit: c7f62dca74e89659230ebc7a02d290cd62dd8323
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Signed-off-by: Hamza Islam (hisl) <hisl@odoo.com>
Current behavior:
If you apply a fiscal position on a POS order, then refund it, the
fiscal position is not applied on the refund order.
Steps to reproduce:
- Create a fiscal position that match 15% of taxes to 0% of taxes
- Create a POS order with a product that has 15% of taxes
- Apply the fiscal position on the order
- Refund the order
- Check the taxes on the refund order, they are not correct
opw-3371028
closesodoo/odoo#132768
X-original-commit: 09dbf51e88ea76934634e1b2f4c0292e83f4c9e4
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
When using a list view for an x2many field in a form view, the parent node
containing the list view will adapt its size to its contents. This can be a
problem for the list renderer as it calculates the allowed total table width
from the width of the parent node.
To resolve the issue we make sure the table does not cause any overflows at the
moment the allowed width is computed, just before the calculation of the column
widths.
Steps to reproduce:
Go to Inventory > Inventory Adjustments > Select a product from a line
In the many2many additional_product_tag_ids add a tag with a name longer than
the width of the column. Now all the labels in the column are broken (they will
wrap after every character).
opw-3358116
closesodoo/odoo#132759
X-original-commit: 1fa97b5a814ca678b831ef0545fd5a24f577c979
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Signed-off-by: Tom De Caluwé (tdc) <tdc@odoo.com>
Current behavior:
If you make a sale in the PoS without invoicing it, the vat amount in
the tax report was no correctly computed.
Steps to reproduce:
- Install l10n_ae
- Create a payment method and a PoS with this payment method
- Create a product with a price of 100 AED and the tax of 5% (Dubai)
- Make 2 pos orders with this product, one with invoicing and one
without
- To see the VAT Amount we need to add it with studio, go in accounting
-> journal items -> studio -> existing field -> "vat amount"
- Go in the accounting app and go for the Tax Report, change the date
range to the financial year. Now click on "Dubai" in the "Standard
Rated Supplies (Base)" section. And click on "Audit"
- You will see that the VAT amount of the order is 0 when it should be 5
opw-3293589
closesodoo/odoo#132755
X-original-commit: cf261f5b6c9ec5d9d68bb7808e164ebdb85bb6ce
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Before this commit, a user was unable to modify an event if the
organizer was not in the attendee list and when notifications were set
to "handle in Odoo" in Preferences.
Steps to reproduce:
1. Install Calendar
2. Create another user, Person B
3. set notifications to "handle in Odoo" in Preferences for all users
4. Log in as Marc Demo and create and edit a meeting for Person B
excluding himself at the attendee
5. Log in as Admin, and try modifying the start date of the meeting to
a future date
6. AccessError is thrown
opw-3299168
closesodoo/odoo#132745
X-original-commit: dec956f88961af0759e0108306a54c16e60d9d2e
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
In our continued effort to remove legacy code, this commit replaces
usage of the legacy DropMisordered util with the KeepLast util. The legacy
DropMisordered has been removed.
Part-of task-id 3439226
closesodoo/odoo#132559
Related: odoo/enterprise#46027
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In our continued effort to remove legacy code, this commit remove the
the legacy rejectAfter util as it's not used anymore.
Part-of task-id 3439226
Part-of: odoo/odoo#132559
In our continued effort to remove legacy code, this commit replaces
usage of the legacy delay util with a new delay util. The legacy
delay has been removed.
Part-of task-id 3439226
Part-of: odoo/odoo#132559
In our continued effort to remove legacy code, this commit replaces
usage of the legacy DropPrevious util with the KeepLast util. The legacy
DropPrevious has been removed.
Part-of task-id 3439226
Part-of: odoo/odoo#132559
Prior to this commit, alert was in the status bar. To maintain
consistency and avoid alert being in a dropdown in mobile, alert should
be below the status bar.
There was also a height issue that created a too high alert in
`mass_mailing_sms`.
This commit fixes these issues.
task-3468540
Part of task-3326263
closesodoo/odoo#132753
X-original-commit: da9d1c5e146fe0370204d3330cf3d876a98f5753
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
this commit focus on improvement in availability field for applicant. add a
placeholder when availability field is empty to show the availability as
"Directly Available". add demo data for applicant availability for testing and
demonstration purposes. create a filter "Directly Available" to get the data of
applicant who are available to start work.
task-3349713
closesodoo/odoo#126372
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
before this commit, the repair orders is directly
linked with the root menu of repair application and if you user opens the repair app, repair orders
action is shown as it is linked with the main menu.
similarly in the calendar app, the calendar is linked
with the root menu calendar.
but now if user move to reporting or configuration menu of repair app, there is no menu to access the repair orders.
with the new milk redesign on clicking the root menu user will be taken to home screen, where us there is hamburger menu in previous design to navigate to home screen.
so only way for user to access the repair order menu is to go back to home screen and come back.
similarly in the calendar app, if user takes the
configuration menu, in order to access the calendar, user
has to go to home screen and come back.
after this commit, a new sub menu is introduced in both
app and moved the action linked with root menu to
the newly added sub menu.
closesodoo/odoo#126329
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
- install l10n_it_edi
- create a bill and set the move line with a tax "RC"
- confirm
-> the blue banner edi appears
- reset to draft
- change the tax to a non "RC" tax
- post the bill
Issue:
Despite resetting the bill to draft state and rectifying the tax configuration, the document could still undergo unintended processing as a Reverse Charge Bill.
Solution:
Reverse Charge bills, particularly those involving Intra-EU transactions, mandate that the VAT be paid by the buyer rather than the seller.
Italian EDI regulations necessitate the submission of such bills to the Tax Agency, specifying the buyer's tax obligations through a process known as tax-integration or self-invoicing.
In cases where an incorrect Reverse Charge tax is mistakenly applied to a domestic vendor bill, the existing issue becomes evident.
Even if the bill is Reset to Draft and the incorrect tax is removed, the associated edi_document will still be existing and will still have its "to_send" state. Consequently, the Scheduled action incorrectly attempts to send it.
This commit rectifies the problem by ensuring that when a bill is reset to draft state, the associated edi_document is promptly deleted.
The document will be recreated only during the posting process, should it genuinely require submission to the tax agency.
opw-3281007
closesodoo/odoo#132752
X-original-commit: f2c973a970af947a0e77a5e835237b09f11bdf7e
Related: odoo/enterprise#46112
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Was removed during the watch refactoring of #111422, present to avoid
people merging `watch=True`.
closesodoo/odoo#132727
X-original-commit: d2b33743e1b6faef82b24eb1e30b142e6b072290
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Current behavior:
The opening difference is counted twice when printing the session report
So the expected cash amount is wrong.
It was happening because the opening difference was counted in the
cash_register_balance_start and also in the cash_real_transaction.
So we use the previous session closing balance to only coun the opening
difference once.
Steps to reproduce:
- Open a PoS session with 100€ in the cash register and close it.
- Reopen the session and enter 50€ in the cash register.
(The opening difference is 50€)
- Make a sale for 10€, using cash payment.
- Close the session and print the session report.
- The expected cash amount will be 10€ when it should be 60€.
opw-3384313
closesodoo/odoo#132690
X-original-commit: fce504ad1cdfd7c90fe85fcb7965524dc122ebac
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
RATIONALE
As multi-company tolerant alias domains will soon replace the usage of
configuration parameters, having them in base then replaced by more advanced
models in mail would be complicated to handle and not useful. Move those
ICP to 'mail' so that all mail configuration is done in that module.
SPECIFICATIONS
Move config parameter used for alias domains configuration in 'mail' module.
Base should be as simple as possible and let mail deal with mail server
complexity.
Move 'mail.{bounce/catchall}.alias' used with 'mail.alias.domain' to make
bounce and catchall emails. Move 'mail.default.from' as it will be integrated
into alias domains in some form.
Note that 'mail.default.from_filter' stays as an ICP in base as it is a
more global default parameter. It is used as default value in 'connect' when
no mail_server is used and no from_filter can be retrieved.
Some tests in 'base' are either fixed, either moved directly into 'mail'.
We now differentiate base behavior (without ICP) from configurable behavior
(with ICP in mail).
Split '_get_test_email_addresses' into two methods allowing to generate the
'from' and 'to' when testing SMTP connection. Improve test coverage, notably
for edge cases.
See sub commits for more details.
LINKS
Preparation for MC aliases, following
* odoo/odoo#130768 + odoo/enterprise#45204 (test suite preparation)
* odoo/odoo#130632 + odoo/enterprise#45118 (alias cleanup)
* odoo/odoo#131492 (mail server test preparation)
See odoo/odoo#76734 and odoo/enterprise#20983 for MC Alias PR.
Task-3453347 (Mail: Move Mail ICP from Base to Mail)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#130750
Related: odoo/enterprise#46000
Related: odoo/upgrade#5025
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
RATIONALE
As multi-company tolerant alias domains will soon replace the usage of
configuration parameters, having them in base then replaced by more advanced
models in mail would be complicated to handle and not useful. Move those
ICP to 'mail' so that all mail configuration is done in that module.
SPECIFICATIONS
Move config parameter used for alias domains configuration in 'mail' module.
Base should be as simple as possible and let mail deal with mail server
complexity.
Move 'mail.{bounce/catchall}.alias' used with 'mail.alias.domain' to make
bounce and catchall emails. Move 'mail.default.from' as it will be integrated
into alias domains in some form.
Note that 'mail.default.from_filter' stays as an ICP in base as it is a
more global default parameter. It is used as default value in 'connect' when
no mail_server is used and no from_filter can be retrieved.
Some tests in 'base' are either fixed, either moved directly into 'mail'.
We now differentiate base behavior (without ICP) from configurable behavior
(with ICP in mail).
Task-3453347 (Mail: Move Mail ICP from Base to Mail)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130750
From filter could be ill-defined, like ' ' or ','. This commit just make
some code more defensive against those values.
Task-3453347 (Mail: Move Mail ICP from Base to Mail)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130750
Split '_get_test_email_addresses' into two methods allowing to generate the
'from' and 'to' when testing SMTP connection. As 'email_to' is always the
same better have a small method for it. Moreover it eases overrides if
some code wants to tune the from / to by overriding only the necessary one.
Task-3453347 (Mail: Move Mail ICP from Base to Mail)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130750
Prepares the move of ICP to mail before replacing them by dynamic alias
domains. Improve test coverage, notably for edge cases. Continue to make
tests more explicit after odoo/odoo#131492. Some tests are also merged to
lessen number of different tests when possible, notably when only a test
parameter differs (like giving an SMTP session or not).
Clean ICP and mail servers setup in test classes allowing to remove some
unnecessary extra initialization. Cleanup a mock in mail.
Task-3453347 (Mail: Move Mail ICP from Base to Mail)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130750
* = hr, im_livechat
The real service works just as well, gives more guarantee on what is
actually tested, and requires less lines of code.
closesodoo/odoo#132744
Related: odoo/enterprise#46108
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
In the event.registration form it can be hard to tell which event the
attendee belongs to at first sight if the event name is too long and
there are several ones with the same root.
Same approach as in https://github.com/odoo/odoo/pull/94315
TT44730
closesodoo/odoo#132730
X-original-commit: a10a0d66eaa841f114f7b0b3d79de124ee2d7fb0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This addresses an issue with the current Google and Microsoft
Calendar synchronization feature in Odoo. It aims to prevent
inadvertent modifications on calendars in a duplicate database.
opw-3382489
closesodoo/odoo#132698
X-original-commit: 9c94804893cf41eb91aaa8750bf2d9a59f513158
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
In a SaaS server, the _meta_data variable will be translated when the
HTTP worker is spawned and it will be translated into whichever language
is set on the DB that spawns said worker. This causes issues when other
DBs use this worker as the variable may be translated into a language that is
not present in that DB. To rectify this issue, we use lazy translate so
the translation lookup is executed at rendering.
opw-3385997
closesodoo/odoo#132691
X-original-commit: b7a538998cfbb2428e6575bbac892a9aff26f0c5
Signed-off-by: Simon Goffaux (sigo) <sigo@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When inserting a link into mass_mailing document
we need to delay the blur event to prevent the to_inline.
If the to_inline is called when the link dialog is open
the context is lost in the document and the link failed
to be inserted.
task-3234749
closesodoo/odoo#132667
X-original-commit: db38abf259c1a6fed51e8e99785ffea770e9e909
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
The field manual_consumption field on mrp.bom is computed,
`readonly=False` should be added to make sure it's changable.
Also on the form view, `force_save="1"` should be added to make sure the
value will be saved since we make it readonly in some cases on the view.
closesodoo/odoo#132600
X-original-commit: 4bdfd0d1e0d95af92a1afae5888e9e587fc4994e
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
Alexandre Kühn