Inserting text that contain multiline does not work.
One "\n" is removed.
Two "\n" become only one.
Task ID: 2602881
closesodoo/odoo#73835
X-original-commit: 89450137653526d9947bc21410cc4163e8b9b440
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Purpose
=======
If the counters are enabled, this could lead to inconsistent counts,
as the session context (with allowed_company_ids) is not passed, and the
multi-company rules are not applied properly if we fall back on another
company that the ones on which the user is logged.
Popover has some style by default (eg. padding), but it is not always desirable
(eg. if the content has a scrollbar, having padding to the right of the
scrollbar is not good).
-> Add a class to allow overriding the default style in the legacy popover.
closesodoo/odoo#73655
Note: the new popover already has this prop.
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Some characters were overlapped in the printed receipt or receipt sent by email because the library html2canvas doesn't handle well the css wrapping (e.g. in the German localization) by default.
closesodoo/odoo#73594
X-original-commit: debab4026f4f4bf380cba3bcb65c223cc4e1bbc9
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Before this commit, some tests were indirectly using demo data.
For example `env['res.partner'].search([])` would return demo data in
addition to the partners created for the tests.
This commit changes that by ensuring that the records used are limited
to the records made for the tests. Some values have been adjusted to
account for the lower amount of available records.
closesodoo/odoo#72553
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit, for an EDI to be successfully posted, returning an attachment from 'post_invoice_edi' was required. In some cases this caused problem:
- When an EDI is posted in two steps, sometimes the attachment is generated in the first step and nothing is returned until the second step. This forced to do some hack where the reference to the attachment in a seperate field to be able to return it after the second step.
- When an EDI doesn't have a file to return (maybe we just send data over an API and get a response without any file involved).
Now, the attachment are removed from account_edi flows. When returning from 'post_invoice_edi', it is still possible to return an attachment whose reference will be kept in the edi_document, but will not change the state of the document to 'sent'.
To make the state change to 'sent', 'post_invoice_edi' must return {'success': True}.
Nothing has changed in the 'cancel' flow, meaning that the buttons related to canceling or reseting an invoice to draft are now based on the state and not on the existence of an attachment on the document. Also, when an invoice is successfully cancelled, the reference to the attachment is STILL removed from the document, since the document does not represent an electronic invoice anymore.
closesodoo/odoo#70040
Related: odoo/upgrade#1946
Related: odoo/enterprise#13220
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
In some cases, non-generic operation needs to be done when retrying to process and edi.document.
For example : for web-services with two steps, if there is an error we need to restart the two steps (and therefore reset the internal state of the edi to the first step, typically by deleting the transaction_id). In case of a warning, we want to retry the second step. This can only be done in the non-generic part of the code, so a hook is added in `account.move`.
Before this commit, if a related field's path definition contained a
non-existing field (either because of a typo or field removal) the ORM
would simply send a generic Python KeyError that didn't really help in
debugging.
With this commit, we raise our own KeyError stating which related field
has the wrong path definition and exactly which field within the path is
incorrect.
See test for an example.
closesodoo/odoo#31889
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Assigning to const variable is always a programming error, and we almost
never want to have a debugger in production code (for those cases, an
ignore comment can be added).
closesodoo/odoo#73821
Related: odoo/enterprise#19694
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The terms 'Set Customer' and 'Deselect Customer' was missing
in point_of_sale.pot
opw-2596436
closesodoo/odoo#73800
X-original-commit: 9e7253b620915c7773dabf705107418c61dac722
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: guva-odoo <guva-odoo@users.noreply.github.com>
Step to follow
- Create a product with 2 variants and set route to Manufacture
- Create a BOM for the product
- Create an MO for one of the variants
- Save (in Draft State)
- Edit
- Change to the other variant
- Confirm
- Finish the MO Order
- Look at product moves on MO
Cause of the issue
In MrpProduction._onchange_move_finished method, self.move_finished_ids
was not empty before being assign.
Solution
Removed the records from self.move_finished_ids before
assign another one to it.
opw-2572644
closesodoo/odoo#73563
X-original-commit: 5e34a02c3d897d888bf52b1977c25047326b76a8
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: guva-odoo <guva-odoo@users.noreply.github.com>
Right now, if we want to add a quiz to the event track, we need to
create it from the m2o field available in the form view. But it is
not very intuitive as user will have to select 'Create and Edit'
option from the m2o drop-down. Quick create is not really helpful
here. Also, trying to add question for the quiz will pile up the
modals which looks messy.
With this commit, in the event track's form view, we:
- Remove the m2o for `quiz_id` (from the track form view, not from model)
- Introduce "Add Quiz" header button, which redirects user to form view
of the quiz, with no option to create new quiz directly as only one quiz
should be linked to quiz. Also, once the quiz is added, this button will
be hidden.
- Introduce new stat button "Go to Quiz", which redirects user to the form
view of quiz (again, does not allow creation from the same reason). This
button is visible only if the quiz is already added for the track.
Apart from that, re-arrage the quiz form view `event_quiz_view_form` by
putting 'Event' and 'Event Track' fields on the same line, and we utilize
the same view while creating / updating quiz from the track.
Note:
Since the creation of quiz is now done in its own form view (with action button
"Add Quiz" from track's form view), we are passing the default `event_track_id`
while creating the quiz. It means that we don't need to compute it anymore.
Instead, now we need to compute the `quiz_id` on the track, based on the
`event_track_id` field alreay set on the quiz.
So, we introduce new One2Many `quiz_ids` field to compute the `quiz_id` on the
track, and we remove `event_track_ids` from the quiz. Basically, the logic of
setting `quiz_id` (on the track) and `event_track_id` (on the quiz) is inverted
with the commit, and the demo data is updated accordinlgy.
TaskID-2486552
closesodoo/odoo#70067
Related: odoo/upgrade#2522
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When confirming a SO, if the costing method of a product's category is
not `Standard' and if the SO's currency is different from the company's
currency, the cost of the product won't be converted to the SO's
currency
To reproduce the error:
1. In Settings, enable:
- Margins
- Multi-Currencies
2. Create a product category PC:
- Costing Method: FIFO
3. Create a product P:
- Product Type: Storable
- Product Category: PC
- Sales Price: 200
- Cost: 100
4. Update P's quantity to 1
5. Create a pricelist PL:
- Currency: EUR
6. Create a SO:
- Pricelist: PL
- Order Lines:
- 1 x P
7. Add field "Cost" to the tree view of the order lines
- The value is correctly converted
8. Confirm the SO
Error: The cost of the order line is now 100€. This is actually the USD
cost, it should be converted
This code applies the same conversion as when the cost method is
standard:
https://github.com/odoo/odoo/blob/8a8ff03f6111f377bcd9c2b0f584c450b82a4182/addons/sale_margin/models/sale_order.py#L42-L48
OPW-2563442
closesodoo/odoo#73786
X-original-commit: 04e4cd91637c836b4d856b8638d88c5cf1770421
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Codice Fiscale can be 16 length (letters + digits) for physical people.
Codice Fiscale can be 11 digits prefixed or not with 'IT' for companies.
An error is raised if the codice fiscale is not saved in the correct format. When registering to l10n_it_edi_proxy, we try to normalize the Codice Fiscale if possible.
Also, when entering the vat in the partner, the Codice Fiscale is automatically set normalized.
closesodoo/odoo#73774
X-original-commit: 3741e141e5a468b8ce0413f4f7d7fc05751b0c1b
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
Steps to reproduce the bug:
- Let's consider an expense E paid by the company
- Validate E and post journal entries
Bug:
Two journal entries were created:
1. Outstanding payments (debit) / Account Payable (credit) as draft
2. Expense (debit) / Outstanding payments (credit) as posted
With the this fix:
Only the second entry is created and posted
This reverts commit 25ac51e01a2084afd7a4d5e9c4c87a50ea787b93.
opw:2510663
closesodoo/odoo#73715
X-original-commit: 3add44d462deebb2b7600d0bd2d86a4af8b2ab4e
Signed-off-by: William André (wan) <wan@odoo.com>
In some specific cases, a serialization error can happen on the account
move if it's not a move to cancel. If it happens, the full process
starts again for that move, which includes the requests sent to the
PAC in MX accounting.
It will send 2 CFDI files for the same invoices and the PAC will
interpret that as 2 different invoices, which is a problem.
This fix ensure that the concerned account moves are always locked
to avoid this kind of issue
opw-2489399
opw-2529134
closesodoo/odoo#73789
X-original-commit: bcc4934f80bea4ce70b9edfb22fd40030c5f0063
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This is already there before refactoring in saas-12.4
you can check here https://github.com/odoo/odoo/blob/saas-12.3/addons/l10n_in/models/account_invoice.py\#L73
also add id in group by becouse if there is invoice line have same product,qty and uom then qty is wrong.
For example:
we have there is the same product with the same quantity and UOM like
```
Product | quantity | UOM
=========================
Mobile | 2 | Unit
Mobile | 2 | Unit
```
then tax line is not split so report count qty is 2
opw-2563120
closesodoo/odoo#73803
X-original-commit: 49e6bc9c499a511d479282dc67c1560e1c6bae5b
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: Jigar Vaghela <jva-odoo@users.noreply.github.com>
At the closing of the POS, we try to reconcile
all lines involved in the closing.
If for any reason, a line is already reconciled
(I.E. Debit=0 and Credit=0 is considered as reconciled),
the closing fails because we cannot reconcile an already
reconciled line.
OPW-2602410
closesodoo/odoo#73783
X-original-commit: 4fd374b3f97eee1e706842ce1e28d0ad7a50315a
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
AttributeError: 'HttpRequest' object has no attribute 'is_frontend'
e.g.: when we call request.redirect in ensure_db(), before that the _dispatch
method check if it is a is_frontend route or not.
closesodoo/odoo#73759
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Despite that Werkzeug documentation specify:
'location (str) – the location the response should redirect to.'
Werkzeug support URL as location.
So now Odoo will support URL for request.redirect as argument too.
This commit closes#73729
Re-introduce after discussion with AL the function that allow to specify
a custom placeholder for a specific model.
It has been removed because no more used since we use avatar mixin for
res.users and res.company. But it doesn't means that each model should add
his own mixin and controller and ... Keep it simple!
Use it for product and product template to have a default placeholder more
representative of the model.
Courtesy of xlu-odoo for this design
opw-2513801
closesodoo/odoo#73576
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The journal needs to access the payment acquirers to determine with payment method is still available.
Since the acquirers can't be accessed only for admin users, an accountant doesn't any right to read them, and then, an access error was raised when opening the journal form view.
Also, the 'payment.acquirer' was accessed from the 'account' module instead of being overridden in 'payment'.
closesodoo/odoo#73761
X-original-commit: 7b4580c3756657c902eceb9840984dde76429dcd
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When using drag&drop for adding elements to a product's page through
the website edit mode, users sometimes find the feature confusing to
use. Two examples of said confusion can be seen here:
- https://dashboard.userbrain.net/shared/qwl65bqlk6jg?t=404
- https://dashboard.userbrain.net/shared/k796mnj95pow?t=258
The suggestion for improvement was to reduce height and opacity for
the top and bottom droppable zones (available on all products), and
make any element not explicitly dropped in those zones go to the
zone below the product, available only on the product's own page.
This behaviour is extended to be more generic and is applied when
a dropzone has the class oe_structure_not_nearest, which excludes
it from the nearest search, unless the element is dropped explicitly
in a zone that has the class oe_structure_not_nearest.
task-2581641
closesodoo/odoo#73580
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Currently the replenishment report look for forecasted quantity of
product today. It means that for a product if the delivery is planned
for today the forecast will be -1, at j-1 it will be 0. However for the
majority of use case, products take days to order and arrive.
Example:
- Product A, purchase delivery time 5 days.
- You are the 01-01-2021 and create a SO for 10-01-2021
Currently:
- Product will appear in the replenishment report the 10-01-2021 and
you will receive it the 15-01-2021. So you are late to deliver your
customer.
Desired behavior:
- Product appear in the replenishment report the 05-01-2021 and if you
order it directly you will receive it the 10-01-2021.
If you want to have more time to deliver than one day, security lead
time are there for it.
However the usecase like:
Product arrive in 2 months and you receive it in 3 days, the product won't
appear in the replenish report anymore since the forecast in 3months is
0
It could happens that more product are missing in 3 months than today,
so the system could have more delivery lead times and forecast at date
to compute -> be slower. In that case a parameter could be
added to skip the delivery times computation for each product/warehouse
and just display the forecast in 3 months and let user compute their
schedule themself.
closesodoo/odoo#73737
X-original-commit: f988b7629f8f54e8e3f48bf76e6af9d97b4f47da
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Previously, push_state events triggered from withing window actions
inside dialogs would bubble push their state into the URL even while
within a dialog, this is undesirable as this can cause the URL to become
invalid (eg by pushing the id of a record from an entirely different
model)
This commit fixes that by simply checking whether we are in a dialog
within the adapter before calling pushState.
task-2602458
closesodoo/odoo#73720
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, click on "Schedule activity" in the activity view
would open a dialog in which the search view is the default one on the
current activity view model.
With this commit, we make the dialog use the same search view as the
activity view.
Done to help with the task 2502339
closesodoo/odoo#73697
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: test_website
In a previous commit, the new services and environment were made
available in the frontend. This now allows errors to be handled by the
new error service, and makes the legacy crash manager redundant. This
commit removes it.
Part of #72675
Related: odoo/enterprise#19258
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In previous commits, all references to the legacy notifications and
notification service have been removed, this commit removes the now
unused legacy notification and notification service
Part of #72675
When writing the new webclient, the notification service was rewritten,
and all of its uses in production code were changed to use the new
services, however, some tests were still reliant on the old notification
service.
This commit removes references to the legacy notification service so
that we can be one step closer to removing it from the code base.
Part of #72675
*: http_routing
When rewriting the webclient, a new environment was created, as well as
a new type of service and a new mechanism to start those services. This
environment and the services that go with it were not made available in
the frontend however.
This commit adapts the setup code for the frontend's root widget (and
the website specific equivalent, WebsiteRoot) so that the new
environment exists, and some of the calls to the legacy services are
redirected to the new services. The point is to allow removing some
legacy services whose code is currently only needed by the frontent
because of the lack of availability of this new env and services
Part of #72675
With the introduction of the new webclient, we introduced a new way to
create and interact with registry using categories. This alleviates the
need to explicitly export and import registries.
This commit converts the public root widget's custom registry to use the
new registry to avoid code duplication and having multiple diverging
implementations
Part of #72675
Nicolas Bayet