Steps to reproduce:
- Install Accouting and Expenses
- Activate "Analytic Accounting" in Accounting settings
- Go to "Accounting / Configuration / Analytic Accounting / Analytic Plans"
- Create an analytic plan with the following line:
* Domain: Expense
* Applicability: Mandatory
- Create an analytic account from the plan via "Analytic Accounts" smart button
- Create an expense without analytic
- Create a report from it
- Submit it to manager
- Try to approve it
=> An expected Validation Error will raise:
"One or more lines require a 100% analytic distribution."
- Go to "Expenses / Expense Reports" (list view)
- Select the created expense report
- Try to approve it
Issue:
The report will be approved even if there is no analytic configured on it.
Cause:
"validate_analytic" option is not passed in the context when approving the
report from list view as it is done in form view.
opw-3806787
closesodoo/odoo#160143
X-original-commit: f25a1192454b988f90d454ad9a2706de1415a2ee
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Issue:
When applicant retakes the survey, we only see the first answer of the applicant
from -Consult Interview- smartbutton from the applicant form.
Desired behavior:
We should see the latest answer
closesodoo/odoo#159833
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Odoo implements its own lazy-loading mechanism for the biggest JS
bundles that are loaded on the frontend. This mechanism allows the page
to appear to the user very fast, at the downside of having some
interactive elements (such as buttons) have no effect during the lazy
loading. In general, this is not a problem since:
- Standard links and buttons work, only those with custom effects (a
modal, a custom JS behavior, etc) have no effect.
- The full loading should not take long anyway.
- After the pages have been visited, everything should be in cache.
However, in some cases (countries with poor internet connections), the
experience can be confusing. Without lazy loading, they would have a
page that appears as a blank white page for a few seconds. With our
custom lazy loading, they get the website very fast... but some buttons
appear buggy (no effect) for a few seconds.
The long term plan is to review our lazy loading:
- Should it be less delayed than it currently is? (at the time, this was
the minimum delay that made Google give us good page scoring but it
may not be as impacting as before)
- Should some of the lazy-loaded JS should actually not be?
- Should the assets be split differently?
- Could we be able to remove some code that weighs too much?
- ...?
Meanwhile, this commit improves the behavior this way: during lazy
loading, any click on a button is now ignored but a loading effect is
displayed. Once the JS is fully loaded, the click is then re-played on
the previously clicked button, hopefully triggering its effect. In any
case, this cannot be worse than what we have before... except for:
- The reasonable risk we take merging this in stable (we considered
merging in a more recent version but it is needed for some specific
projects and many websites would benefit from this improvement).
- Any custom code that added behavior on buttons to be available during
lazy loading... will just wait for lazy loading with a loading effect
too now. This should be a good compromise as, again, that lazy loading
is cached and should not take too long anyway.
Note that this replaces the previous o_wait_lazy_js class behavior (it
has now no effect).
Overall:
- This should not impact (neither improve nor worsen) most websites that
are currently experienced from good internet connections.
- This should be a big improvement for most websites that are currently
experienced from bad internet connections.
Related to task-3770362
closesodoo/odoo#159680
X-original-commit: 6aeebe47dd552144fabd42ddb190021f1499e38a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
As a preparation for the upcoming improvements in the lazyloader, this
moves the code around a bit. This will ease the review later. This
also actually removes code that was totally useless in that moved code.
Related to task-3770362
X-original-commit: aef5a7631723f3e26425427a963c1a0dd7b6d133
Part-of: odoo/odoo#159680
In the future, we might want to make most utils available in the non
lazy JS bundle part. We are also considering moving the Bootstrap lib
and some more in there. This commit is about moving the strict minimum
to be able to improve the lazy loading behavior in stable: the DOM utils
that allow to make async handlers and create button loading effects when
we click on them.
This also means that those utils were adapted to not use jQuery and
other non available utils.
Related to task-3770362
X-original-commit: 2e922105d8714704b3db94966defc922297e2ab6
Part-of: odoo/odoo#159680
The warning message when you have a half-day off confirmed while the
duration of this leave's type is daily is moved
towards the bottom of the sheet to avoid overlap between this
message and the ribbon.
And to improve the readibility of the dialog view, the scroll bar is
removed when it's not needed.
closesodoo/odoo#159454
Task: 3820211
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce:
- Install l10n_mx_edi
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Create an invoice:
* Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA)
* Product: [any product with UNSPSC Category set]
- Confirm the invoice
- Go to the portal preview of the invoice
- Download the invoice from portal
Issue:
1) On the invoice, the CFDI document has been generated and processed
without notice.
Downloading an invoice from portal should only download the invoice.
2) There are 2 buttons on the portal: "Download" and "Print".
The "Print" allows to print the invoice, even if it has not been
generated and sent yet.
Cause:
When downloading an invoice from portal, we are going through the
"Send & Print" wizard (without displaying it) with only "Download"
option checked.
However, some localization (e.g. MX) may add specific options that
are checked by default (e.g. CFDI), which triggers the corresponding
flow.
Solution:
1) Make sure that all options of "Send & Print" wizard are deactivated,
except "Download".
Download existing invoice documents or generate a temporary Pro Forma
document when downloading invoice from portal.
2) Remove "Print" button from portal view.
opw-3821371
closesodoo/odoo#159255
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Versions
--------
- 17.0
- saas-17.1
Steps
-----
1. Have `calendar` and `hr_homeworking` installed;
2. go to Calendar;
3. try to set a location by clicking on a date column.
Issue
-----
Odoo Client Error.
Cause
-----
The `onDayRender` function calls `onDateClick` to create a record,
passing an `info` object lacking the `jsEvent` attribute.
Solution
--------
Use `this.props.createRecord` instead.
closesodoo/odoo#159060
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Steps to reproduce:
- Install Invoicing
- Create a product with $0 cost (e.g. Product X)
- Create a vendor bill:
* Vendor: [any]
* Invoice Lines:
- Product: [none]
- Label: [anything]
- Price: [any]
- Taxes: [any]
=> The displayed "Untaxed Amount", "Taxes" and "Total" are correct
- Save the vendor bill
- Edit the invoice line of the bill
- Add Product X
=> "Untaxed Amount", "Taxes" and "Total" are correctly set to 0 as expected
- Change Price to 100 manually
Issue:
"Untaxed Amount", "Taxes" and "Total" stay at $0.
Upon save, "Untaxed Amount" is correctly set to $100, but "Taxes" stays at $0.
If "Units of Measure" option is activated in the Settings (available with Sales,
Purchase or Inventory app), the user will be in "uom.group_uom" and the issue will
not happen.
Cause:
When the user isn't in "uom.group_uom" group, "product_uom_id" field is
declared after "price_unit" field in the view.
Due to that, adding a product in the invoice line and changing the price to $100,
will first set "price_unit" to $100 and then set "product_uom_id" that will trigger
"_compute_price_unit" method where "price_unit" is recomputed to $0 (its cost).
Solution:
Move "product_uom_id" field before "price_unit" field in the view as it is the case
when the user is in "uom.group_uom" group.
opw-3750740
closesodoo/odoo#156447
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Have an x2many with several pages containing a field with a
readonly modifier (in the view, not in the field definition), e.g.
`readonly="1"` in the arch. Have an onchange that returns an
UPDATE command for a record that isn't in page 1 (so a record we
haven't read), with a value for that readonly field. Before this
commit, the value was sent in the UPDATE command, even though
readonly fields shouldn't be sent.
The difficulty here is that we can't always evaluate those readonly
expressions, as they can depend on other fields, which we didn't
read if the record is in a page we didn't browse to yet. However,
"static" expression like `"1"`, or `"context.get('something')"`
can totally be evaluated, and they should. This is what this commit
does.
Steps to reproduce the issue:
- Install mrp
- Go to Manufacturing > Products > Bill of Materials
- New:
- Product: quick create "B1"
- Components: two lines: quick create "C1" and "C2"
- Save
- Manufacturing > Operations > Manufacturing Orders
- New [in that form view, set the limit of the x2many to 1]:
- Product: "B1"
- Save
- Change quantity to 2
- Save
=> Invalid Operation
opw 3819253
closesodoo/odoo#160129
Signed-off-by: Géry Debongnie <ged@odoo.com>
Steps to Reproduce
- open project
- open project settings and mark task dependencies
- open task
Issue
- The title is super far from the left.
Cause
- Every field have the same width.
Fix
- We fix the width of priority and state.
task-3761269
closesodoo/odoo#159949
X-original-commit: 96f225fee0e9b7b0213a5e63f261d3e8b8ace2bd
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This traceback arises when the user changes the date with a new employee
of no contract, while creating a new Work Entry.
To reproduce this issue:
Install "hr_work_entry_contract"
1) Open payroll and create a new "Work Entry"
2) Select Work Entry Type as Unpaid and create a new employee
3) Now try to change the date
Error:- 'KeyError: False'
On the '_get_duration_batch' method, when the user creates a new employee
without a contract, the calendar remains an empty recordset.
which leads to the traceback from the below lines.
https://github.com/odoo/odoo/blob/a277faa2ffab7559fcbad95fcc1e8fd6a26d756b/addons/hr_work_entry_contract/models/hr_work_entry.py#L110-L112
After applying this commit will resolve the issue by making code more robust and
give default value.
sentry-5095168051
closesodoo/odoo#159958
X-original-commit: dff6e723580162044d25e98e0394d28e00bab520
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When a background video and an animation coming from the left or the
right are on a page at the same time, there sometimes is a horizontal
scrollbar that appears for no reason. It can happen at any screen size
but more frequently near 1000px and below. This issue seems to happen on
Chrome only.
It seems to be a race condition between the calls to the `_adjustIframe`
function in the `backgroundVideo` public widget. Indeed, this function
is called when the video is added in the DOM and each time the screen is
resized. When an animation is played, it triggers a resize of the window
when it is over, which therefore calls `_adjustIframe`.
When the animation comes from the right/left of the screen, the animated
element is translated from outside the page; the page width is therefore
bigger but its overflow is prevented. When the video is loaded, the
loading placeholder is removed. Depending on the time it takes to it to
fully load, if the animation ends before it, the iframe is adjusted
before the placeholder removal, leaving the iframe wrongly adjusted when
it is finally removed.
Note that it is hypothetical, as everything refreshes when inspecting
the DOM, making the scrollbar disappear. But this proves that no element
is really overflowing, so it seems to be a value refreshing issue.
This commit adds a call to `_adjustIframe` when the video has loaded, to
make sure its dimensions are recomputed/refreshed, preventing the
scrollbar to appear.
Steps to reproduce:
- Drop a "Text-Image" snippet.
- Set a background video to it.
- Add the "On Appearance" > "Fade" > "From Right" animation to the image
column.
- Save and then resize down the screen to 1000px or below.
- Refresh.
=> When the video is loaded, a horizontal scrollbar may appear. If not,
refresh until it does.
opw-3487117
closesodoo/odoo#159817
X-original-commit: 6035874e61d2bb1cecc339c4006cdcb6b4084b5c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
In some cases, sorting a sub-view list and then deleting one of its rows can cause a traceback.
This commit corrects this situation.
Here's a way to reproduce the error:
- Install `sale_management`
- Open a quotation
- Put enough elements to have two pages
- Modify the view via debug mode and change the list view limit from "200" to "2".
- Add 4 elements
- Sort with `product_uom_qty` field
- Attempt to delete the second element (i.e. the last element on the first page)
When deleting this line, a traceback is raised
Let's say we have 4 records with the following data
Page 1 (`1 - 2 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 1 | Table | 6 |
| 2 | Lamp | 1 |
Page 2 (`3 - 4 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 3 | Chair | 4 |
| 4 | Board | 3 |
In this case we have two cached elements: the two elements visible on
the first page.
In the cache we have two complete records, by complete we mean a record
containing all the fields, for example:
```js
{
"1": {
id: "datapoint_4",
...
data: {
sequence: 10,
name: "Table",
product_uom_qty: 6,
display_type: false
...
}
},
"2": {
id: "datapoint_11",
...
data: {
sequence: 10,
name: "Lamp",
product_uom_qty: 1,
display_type: false
...
}
}
}
```
After sorting by quantity, we end up with
Page 1 (`1 - 2 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 2 | Lamp | 1 |
| 4 | Board | 3 |
Page 2 (`3 - 4 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 3 | Chair | 4 |
| 1 | Table | 6 |
It also changes at cache level, since we sorted via the `product_uom_qty`
field, we had to go and read the records on the next page (despite the
fact that they weren't displayed).
But as we only need the quantity information, we only fetch this field
from the records on the following pages.
In terms of cache, we have something like this
```js
{
"1": {
id: "datapoint_45",
...
data: {
sequence: 10,
name: "Lamp",
product_uom_qty: 1,
display_type: false
...
}
},
"3": {
id: "datapoint_16",
...
data: {
sequence: 10,
name: "Board",
product_uom_qty: 3,
display_type: false
...
}
},
"4": {
id: "datapoint_32",
...
data: {
sequence: 10,
name: "Table",
product_uom_qty: 6,
display_type: false
...
}
},
"2": { //Chair
id: "datapoint_1",
...
data: {
sequence: 10,
product_uom_qty: 4,
}
}
}
```
We therefore have one new incomplete record in the cache
The problem will occur when we try to delete a record from the first page,
if we delete `Board`, to have this
Page 1 (`1 - 2 / 3`):
| ID | Product | Quantity |
|----|---------|----------|
| 2 | Lamp | 1 |
| 3 | Chair | 4 |
Page 2 (`3 - 3 / 3`):
| ID | Product | Quantity |
|----|---------|----------|
| 1 | Table | 6 |
So we'll have to move the table that was on page 2 to page 1 (in our
case `Table`), except that when we render the list we'll have to compute
the required/readonly/invisible elements, and if we have a field that
has a readonly with the condition `not display_type` in our view, this
will cause a traceback because in the cache we only have this
```js
"4": { //Chair
id: "datapoint_32",
...
data: {
sequence: 10,
product_uom_qty: 4,
}
},
```
`display_type` is definitely not in the data because we considered this
cached record to be complete.
This commit modifies the `StaticList._applyCommands` function to create
datapoints for all records that are not **entirely** loaded via `StaticList._getResIdsToLoad`.
https://github.com/odoo/odoo/blob/00898aef4dbeb469e0cec7eaea387de2755c6426/addons/web/static/src/model/relational_model/static_list.js#L898-L912
opw-3771077
closesodoo/odoo#159264
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Remove 'videocall_location' when not sent by Google, otherwise the local
videocall will be discarded.
closesodoo/odoo#159111
X-original-commit: b56cd52bdd73c193d98fa334e80b363218cc13b9
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Activate "Reception Report" feature
Create a SO for a storable product, confirm.
Create a PO for the same product.
Confirm the PO and check the delivery, open the "Allocation" report
Assign the Product to the delivery of the SO.
Go back to the PO and cancel the order, delivery of the SO will be cancelled.
Issue: Currently the user cannot modify this behavior as the
`propagate_cancel` checkbox is unaccessible
opw-3733512
closesodoo/odoo#159940
X-original-commit: c2059c8d2f9d8f6648a577f2dd44360d699f03cf
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Follow-up of [1]. Commit [2] refactored the way we check if an option
update needs to trigger a page reload: if the option is marked as a
page option (`data-page-options="true"` on the option's main `<div>`),
then it will reload whatever the method used if there is a `reload`
parameter. Note that this `reload` parameter does not make much sense
anymore, it should be reviewed/removed in master.
Problem: [2] made a mistake in its implementation, pushing an array
instead of concatenating it. This worked by chance, as instead of asking
"does this option method requires a reload", it was asking "does this
set of option methods requires a reload"... and in that case, the code
is fallbacking on retrieving common parameters, which `reload` likely
is without custo. This could have been fixed in master only. Given the
very low risk of breaking anything critical updating this code, it was
chosen to prevent a potential crash in custo (which could occur as we
give a wrong parameter type to a main method) and allow overrides to
make `reload` a specific parameter for a specific method without the
need of `data-reload` added in the DOM.
[1]: https://github.com/odoo/odoo/commit/556ae457b02e9c077d09fa9c3f9f1e6c6e26b345
[2]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af#diff-70f7fe38208aa7fe678f18e329d3c11b70065dee723921352b6005774e8bab53R456closesodoo/odoo#159927
X-original-commit: 337fbdc35ee0da2ae9d0a524a8b084c959949c78
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
if there the new_hire_field is False, an error appear. This Commit will check that the field is not false
closesodoo/odoo#159859
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Current behavior:
When you refund an order that was paid with bank and so not rounded,
the refund is rounded wich result in a difference between the original
order and the refund.
This also happens when the original order was paid with multiple
payments and one of them was not rounded and the other was. The refund
will be rounded as one single payment. This also results in a difference
between the original order and the refund.
Steps to reproduce:
- Setup a rounding method with a precision of 5.0
- Create a product with a price of 138.0
- Open the POS and add the product to the order
- Pay the order with 2 payments, one bank of 55 and one cash that will
be rounded to 80.
- Validate the order
- Go in the backend and refund the order
- The refund will be rounded to 135.0
opw-3701574
closesodoo/odoo#159395
X-original-commit: cdae1e34eddccd5ce098c79d845a8fc2658c0175
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
In case we want to search on other fields than name or default_code,
or eventually on the descriptions, we need to reverse the domain
that is built using AND and OR operators from osv.expression which
is something we would prefer to avoid anytime.
By adding a hook to add custom domains, it allows to search on whatever
extra fields we would like to search on.
closesodoo/odoo#159340
X-original-commit: 54c0b97594fb1f489163e993afd0df12cf877501
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The numpad in the PoS was sometimes handling events when it was not
supposed to, leading to unexpected behavior. This was due to the fact
we did not check if there was a buffer holder for the numpad before
triggering the event handler. The check is now done by adding a check
in the _onKeyboardInput method.
closesodoo/odoo#159951
X-original-commit: d05220d797978b5f31f574c532c6a5a117b9f5b9
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit, if there was an error, the PoS stays on
the loading page which was confusing for the user.
owp-3834647
closesodoo/odoo#159710
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Make formatsSpecs heritable to allow programmers adding new inline options
closesodoo/odoo#159293
X-original-commit: 7b61bb654c587e624655904ee5d978e531c70f7b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Some tests on dynamic variants mechanism didn't pass on test
without demo data due to odoo/odoo#143543.
closesodoo/odoo#159933
X-original-commit: 12fe7400d58ef12d78a54e3b12d04c28a9564982
Signed-off-by: Benjamin Hanquin (beha) <beha@odoo.com>
Steps to Reproduce
- open project
- create a project and allow timesheet
- open timesheet and change encoding method to days/half days
- create a task in the project and set allocated time
- open portal view of the task
Issue
- There is no label for allocated time.
Cause
- Condition was added in this commit 82a85d42c86cffcd6e96b0712c8ff9a221f25d87
to show the label if encoding method is not in days.
Fix
- We apply the label for both encoding method of timesheet.
task-3761269
closesodoo/odoo#159939
X-original-commit: d7140c14d29d7e667a11dd0f92fe07117044feed
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Dheeraj Pandey (padh) <padh@odoo.com>
Before this commit:
The `<br>` tags copied from external editing software's were remained unchanged.
After this commit:
Implement breaking element at <br> during HTML paste to adress unwanted
<br> elements introduced by external editing software's or the OS.
This ensures consistent and correct behaviour for all commands.
Note that this change does not break `<li>`, `<blockquote>`, and `<pre>`
elements.
task-2936891
closesodoo/odoo#159875
X-original-commit: 94161376b296140e430d034ac79a40127a567457
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Deependra Solanki (deso) <deso@odoo.com>
When installing the module `account_check_printing`, it is possible
that a MemoryError is raised during the computation
of `_compute_check_number`.
To avoid that, the `_auto_init` function is overridden to create the
field through SQL.
opw-3790729
closesodoo/odoo#159894
X-original-commit: f53376b7fa0dd01ee7f4e776928ae1811d4df30c
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Steps to reproduce:
- Setup sendcloud shipping (shipping product 10-30KG)
- Enable demo payment
- On the website proceed to checkout (customizable desk)
- Select sendcloud (Pay button is disabled)
- Edit website and add terms and conditions
- Now if you uncheck and recheck terms and conditions
- Pay button is enabled although carrier is in error
Fix:
when reenabling the pay button we check that the
carrier is ready but we only check if there's pickup point
ensure that the shipping method is avialable before enabling
the pay button
opw-3698804
closesodoo/odoo#159539
X-original-commit: 7682c4bfc7a15b27e95905a2a0d909278bec9eb6
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
In 2024, Luxembourg has added two new fields in the
monthly, quarterly, and annual reports: 769 and 770 (rate of 17%).
These fields should be added in our reports too.
Part of:
task-3814151
See also:
odoo/enterprise#58837closesodoo/odoo#160027
X-original-commit: f91599dc2ed906fe5e6f7fb6a06fcc959c5202b0
Related: odoo/enterprise#59842
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Currently, users are blocked from downloading the UBL file if the partner
or the company are missing Peppol EAS and Peppol Endpoint fields.
The checkbox is not visible and even if it was visible, the user would
see a UserError asking to fill those values.
Let users download these files but show a banner warning about missing
fields.
closesodoo/odoo#159553closesodoo/odoo#160035
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
The issue:
A new fix has been introduced to solve the mimtype issue with creating an XML file: https://github.com/odoo/odoo/pull/124507
since the attachment create_uid now is the SUPERUSER_ID, when a user with the accounting role (not admin) tried to register a payment on any account.move type (invoice, credit note...) an access error is thrown
The fix:
remove the unused attachment as sudo
opw-3787008
closesodoo/odoo#159985
X-original-commit: 60dd56bf3f67cc944918ad4c23fa1ef5f2036e55
Signed-off-by: William André (wan) <wan@odoo.com>
Currently we assume that all imported invoices are incoming (i.e. bills).
This was i.e. done since the tax agency only sends users bills.
But some clients import invoices from other software (i.e. onboarding/starting).
After this PR we decide whether the invoice is outgoing or ingoing and
import the invoice correctly in either case.
task-3650355
closesodoo/odoo#159889
X-original-commit: 292521ddd566cd3d49df2dd2eb4e2850dc47620a
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
Currently there is the following problem when reloading the chart.
Journals without xmlid may not be matched to chart data correctly
(via code or name).
This then leads to duplicate journals being created / uniqueness
constraint issues on journal codes.
The matching happens in `_pre_reload_data`.
This should only be a problem for upgrade or user created journals
since journals created from the chart data have an xmlid.
The problem was introduced in commit d6695f2892ded178371f6c69cf594037c19ce438 :
(1) We load the chart data in en_US to be able to use the code translations
(2) We switched the language of the loading process to en_US
(to switch the chart data to en_US for the previous point and to
avoid inconsistencies)
When matching journals in the DB by code or name to the chart data:
- We fetch the en_US name of the journals in the DB due to (2);
Code is not translatable.
- We compare those values (journal code / name) against the en_US term
due to (1).
Thus the matching fails.
This commit improves the matching:
We also compare the name and code (still en_US version)
against the translated values.
closesodoo/odoo#159871
X-original-commit: 005ebd59cba6b6ca20c736c46d89259af8bd251a
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
- Add new tax groups for VAT at 5%, 13%, and 15%
- Add taxes of 5% and 15%
- Archive VAT taxes of 5% in sales and 12%
- Configure tax group accounts for the new tax groups
- Add new foreign account tax position tax template at 15% VAT
- Add default company configuration for sale and purchase taxes, with new 15% tax
closesodoo/odoo#159596
Related: odoo/enterprise#59788
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before this commit:
Modifying a location from/to a scrap location should be restricted when
there are move lines with reservation. However, starting from Odoo 17,
the quantity field indicates the reserved quantity only when the move
line's state is different from done.
After this commit:
Only check if there are reservation lines (move lines not in done)
in the location when changing from/to a scrap location to match
the behaviour before Odoo 17.
opw-3815275
closesodoo/odoo#159376
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Steps to reproduce:
- Activate "Storage Locations" in the settings and create a warehouse
- Inventory > Operations > Transfers > Internal
- Create a new internal transfer with a non-zero product move line
- Print the "Picking Operations"
Expected behavior:
The destination of the move should be on the document.
Current behavior:
The report (and hence the printed version) of an internal transfer does
not display the destination of the transfer.
Cause of the issue / fix:
This part of the report is displayed under a `t-elif` condition. However
for internal trasnfers the condition of the `t-if` and of the `t-elif`
are both `true` so that two `t-if` should be used for an appropriate
display of the report.
Note:
Prior to commit 567b8d6, two `t-if` were used.
opw-3797998
closesodoo/odoo#159313
X-original-commit: c59e01f1ed32563da3dd86308bf46a1f2cdb5834
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
This commit updates the parameters passed to the IAP SMS API route
("/api/sms/3/send") to include the DB UUID.
closesodoo/odoo#159714
Task: 3829793
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
In Settings>Inventory>Operations enable "Batch Transfers"
Create a [NonTrackedProd] product:
- Product Type: Storable Product
- Tracking: No tracking
Create a [TrackedProd] product:
- Product Type: Storable Product
- Tracking: By Lots
Make two POs with:
- Prod [NonTrackedProd] qty 1
- Prod [TrackedProd] qty 1
Open Barcode Scanning app
Select "Batch Transfers"
Create a new batch with the incoming transfers from the POs
Set only the [NonTrackedProd] lines as done and validate
Issue: Error will block validation
"You need to supply a Lot/Serial number for products"
The system should let the user validate the operation and create a
backorder instead of blocking the user
opw-3777701
closesodoo/odoo#158330
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
**Issue Description:**
Due to changes in field access rights verification as seen here:
https://github.com/odoo/odoo/blob/494231e796b562162d3bfb19fc8ce7550657cf07/odoo/models.py#L5334-L5345
And the removal of sudo rights for CrmLead:
https://github.com/odoo/odoo/blob/494231e796b562162d3bfb19fc8ce7550657cf07/addons/website_crm_partner_assign/controllers/main.py#L98
Attempting to open a search by domain with the `activity_date_deadline`
field triggers a 403 error:
"You do not have enough rights to access the fields
'activity_date_deadline' on Lead/Opportunity (crm.lead). Please contact
your system administrator."
**Steps to Reproduce:**
1. Install the `website_crm_partner_assign` module.
2. Assign Joel Willis a partner level (via the partner assignment tab in
the `Contact` app).
3. Navigate to CRM, select an opportunity, and assign it to Joel Willis
(using the assigned partner tab in the lead form).
4. Log in to the portal as Joel Willis, navigate to Opportunities, and
click any filter on the activities date `Overdue / today / this week
activities`. This action results in a crash.
**Proposed Solution:**
Since we assume that the domain will always filter opportunities with
assigned to current user, we can:
- Do a first search using sudo with the original domain that might
contain the `activity_date_deadline` field.
- Then do a regular search with the opportunities IDs obtained from of
the first search.
opw-3703583
closesodoo/odoo#154653
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
This error occurs when the user adds a new "Working Schedule" to the resource,
switches to the two-week calendar view, removes all the existing "Working Hours"
lines, and then attempts to add a new line under "Working Hours."
Steps to reproduce:
- Install "resource" module
- Settings -> Technical -> Resource -> Working Schedules
- New -> Switch to 2 week calendar -> Remove all "Working Hours" lines
- Click on Add a line
Traceback: ZeroDivisionError
float division by zero
This commit implements a check for the variable "number_of_days". If the value
of "number_of_days" is zero or not found, the function will return zero.
This ensures that the function behaves appropriately in cases where the number
of days is zero.
https://github.com/odoo/odoo/blob/5177e21aea68959eedc73e0034ed984992392dd7/addons/resource/models/resource_calendar.py#L185
sentry - 5108250957
closesodoo/odoo#159844
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, it is not possible to export sale.report by excel or show the lines.
closesodoo/odoo#159793
X-original-commit: 5d8830cb34f3d34ddc907ad245a4312b18c5c1cf
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce:
OS: Ubuntu 20.04.4 LTS with nautilus
Browser: Google Chrome Version 123.0.6312.58
- type /file command in knowledge
- select a folder and click on open
- traceback occurs
Before this commit:
When a user attempts to upload a folder using /file command, the
processing begins, but the folder is not actually uploaded because the
`getDataURLFromFile` return promise which is not fulfiled. Additionally,
there is no indication of any warnings or errors during the folder
upload process.
After this commit:
If a user attempts to upload a folder instead of a file using the /file
command, it results in a error message in toaster notification.
task-3690847
closesodoo/odoo#159755
X-original-commit: 0b27ac02e499bf15d9f011beda17ab202c1f7a42
Signed-off-by: Damien Abeloos (abd) <abd@odoo.com>
Current behaviour:
When you generate a Delivery Slip for a list
of kit and non kit products with no backorder,
kit and non kit products get mixed.
ie: there are kit products in the section
"products not associated with a kit"
Steps to reproduce:
1. Create 4 products (K1,P1,P2,C1,C2)
2. Create a Bills of Materials for K1
3. Set Type as Kit
4. Add C1 and C2 as components
5. Create a sale quotation for K1, P1, P2
6. Set the quantity at 4 for all products
7. On the quotation, click on Delivery
8. In Done, put 4 for P1 and 3 for C1,C2,P2
9. Validate and select No Backorder
10. Click on Print, Delivery Slip
11. In the document:
12. P2 is in the kit section (K1)
13. C1,C2 in the "not associated with a kit" section
Expected behaviour:
Only C1 and C2 should be in the K1 section
Only P1 and P2 should be in the
"Products not associated with a kit" section
opw-3568390
closesodoo/odoo#159138
X-original-commit: 5d61d7023b3b0a5e6a47ad71bb12d548c797b5f9
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
Description:
Adding missing indexes to support most of the searches on survey's
models to avoid seq.scans and non-selective index scans.
Also adding indexes that are inverse to One2many, or dependencies
of compute fields (as those if not indexes will trigger a seq.scan
when the ORM resolves the dependency tree).
If a domain had multiple criteria, only fields with the highest
selectivity were indexed. This shall also reduce the amount of tuples
returned, reducing IO access and cache trashing.
Cardinality:
survey_survey -> X (reference quantity)
survey_question -> 10X
survey_question_answer -> 50X
survey_user_input -> 330X
survey_user_input_line -> 7200X
Reference:
task-3724844
closesodoo/odoo#158136
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Test 'test_unpack_and_quants_history' may fail with error
```
ERROR: StockQuant.test_unpack_and_quants_history
Traceback (most recent call last):
File "/data/build/odoo/addons/stock/tests/test_quant.py", line 926, in test_unpack_and_quants_history
dst_location = stock_location.child_ids[0]
File "/data/build/odoo/odoo/models.py", line 6189, in __getitem__
return self.browse((self._ids[key],))
IndexError: tuple index out of range
```
closesodoo/odoo#159779
X-original-commit: 87e53b1d8e2e3ac6b8ddb514a8311b622adac366
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Anh Thao Pham (pta)