When importing documents that have a `date` or a `datetime` field
a conversion is done on the format string in case it was still in the
old moment format (e.g. YYYYMMDD).
The problem is that this conversion was done regardless if the format
string was valid or not. This was producing botched format strings that
would prevent any import having a date or datetime field with proper
format string.
closesodoo/odoo#119340
X-original-commit: 20f4102e9aef42c557c6f7e0b5b5e591a18b1b4f
Signed-off-by: Luca Vitali <luvi@odoo.com>
When you create an entry on Miscellaneous Operations journal and
schedule an activity on that entry, the Accounting dashboard
crashes and gets completely inaccessible because of an untranslated
field on mail.activity.type.
closesodoo/odoo#119318
Task: 3283382
Opw: 3277677
X-original-commit: 14481724cb5d6a164332586eb18f3195c6508b12
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Claire Bretton <clbr@odoo.com>
It is only used there.
In preparation of splitting discuss and mail modules.
Part of task-3265211
closesodoo/odoo#119302
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
For some reasons, we need to store information about a transaction
in the bank statement line. This commit adds the field to handle
this information.
task-3270965
closesodoo/odoo#118943
Related: odoo/enterprise#39955
Signed-off-by: Laurent Smet <las@odoo.com>
Reduce the CoA which was too complete in regards with the business need.
Add the tax report mostly based on the series G°50 official document (only VAT part).
New taxes have been added to correspond to the tax report.
New fiscal position have been added.
Official documents must be in French -> add a French translation.
All references can be found in task details
task-3047876
closesodoo/odoo#113165
Related: odoo/enterprise#37298
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
**Steps to reproduce :**
- Create a Product A, with no stock and a 0 min 1 max manual reordering rule (no sales lead time, no purchase lead time)
- Sell 10 of A with a delivery scheduled today
- In Replenishment, create a PO for A, confirm it with reception scheduled today
- Reschedule reception of PO in 7 days
**Expected Behavior :**
The forecast icon is replaced by an orange warning icon.
When hovering the icon, the user is warned that replenishing can lead to an overstock.
**Current behavior :**
In Replenishment, Product A has a forecast of -10 and Qty to Order is set to 11.
When the user replenish A again, the PO is created and may lead to an overstock.
task : 2918947
closesodoo/odoo#97802
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
In edit mode, if the grid mode is toggled and if there are enough
options in the right panel to have a vertical scrollbar (e.g. when we
click on an image to have the image options), a horizontal scrollbar
appears. This happens because the "Add Elements" widget is too large and
it therefore overflows.
This commit improves this widget style so it does not overflow, which
will prevent the horizontal scrollbar from appearing.
task-3098222
closesodoo/odoo#119288
X-original-commit: 784a8f36471a6b7c05452f6b39ee61f6b859d9c9
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Before this commit, when adding a tag on record and then
scheduling an activity, the tag was removed from the record.
This happens because reloading the chatter does not save changes.
Although there is a `keepChanges: true` option, this looks
ineffective. This commit fixes the issue by letting chatter reload
always save any changes.
closesodoo/odoo#119275
X-original-commit: 97465dfb0ec53080bf05c3614dfa7429629729a6
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit changes the js transpiler to write sync module.
The goal is to remove all async module and simplify the
module loader in the future.
task id: 3265979
closesodoo/odoo#119186
Signed-off-by: Géry Debongnie <ged@odoo.com>
Have a multi edit list view, select several records and edit a
field represented by an input (e.g. a char field). After typing the
new value, press ENTER to validate. The confirmation dialog opens,
click on OK/Confirm to save. Before this commit, an error was
thrown afterwards, because we tried to retrieve the value from the
input, but the input doesn't exist anymore as the edited row has
already been switched back to readonly. This commit fixes the
issue.
closesodoo/odoo#119082
Related: odoo/enterprise#40012
Signed-off-by: Géry Debongnie <ged@odoo.com>
The primary goal of this commit is to simplify the RelationalModel
API, and in particular to remove its "fieldNodes" param, which was
only necessary for a list specific usecase, which is the opening of
the ListConfirmationDialog when multi editing. We also remove the
"blockUpdate" logic from the model s.t. it remains local to the
list controller. About this logic, we fix a minor issue as we no
longer open the "No valid record to save" dialog when the mousedown
event is trigerred on "Discard" (we instead wait for the mouseup,
like already done to open the multi save confirmation dialog).
Part of task 3179751
Part-of: odoo/odoo#119082
If a partner has no VAT number (for instance: a public administration),
the xml tag `PartyTaxScheme` should not appear for UBL Bis 3.
opw-3263542
closesodoo/odoo#119261
X-original-commit: 270ed9f92ee9c71cc38c4cc69fb2d7c2c780cf52
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
The jobs / departments / offices were not in alphabetical order but
ordered by the job they were in, which didn't make sense.
task-3278949
closesodoo/odoo#119260
X-original-commit: 5da763a8ef0503286fa5cc55e32970f4d785825a
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit there is a sub-type to notify parent
if child stage change but with new to-do state feature
we don't to unnecessory notification on parent which is
more problemation then informative.
This commit remove task dependency sub-type and it's related
code.
task-3252755
closesodoo/odoo#118418
Related: odoo/enterprise#39972
Related: odoo/upgrade#4542
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Given that `assertRecordValues()` is order-dependant to check the
values, ensures that the pickings given in the test are in a fixed
order.
If the test is run too quickly, both delivery picking and return picking
would have the same scheduled date, ordering them by 'id desc' since
both priority and scheduled date would be equals. Sorting them manually
ensures their order is consistent, and thus the assert checks the right
values.
closesodoo/odoo#119282
X-original-commit: 9bc41db19b6da7947b2d430d47de1c8f3220765b
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Before this commit:
When we write a long pad and go to bottom a insert a link when the modal opens
the editable area scrolls to the top.
After this commit:
Now from the bottom of the pad when we insert a link the editable area does not
scrolls to the top.
task - 3138700
closesodoo/odoo#119279
X-original-commit: 2c50808d9cebc7ba0913a098bf79a15ef36da47f
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
## Summary
The early payment discount (EPD) grouping functionality can break when
using taxes that add tax tags on their base lines.
## Steps to Reproduce
1. Install the `l10n_be` module
2. Ensure that `Cash Discount Tax Reduction` in the settings is set to
`Always (upon invoice)`
3. Create a bill and set the payment term to `2/7 Net 30`
4. Add a product line (`l1`) with any Belgian tax and save
5. Add the same product line again (`l2`) and save
6. Attempt to add another product line or remove an existing one and
save: an error will occur, stating that the move is not balanced
## Cause
The EPD grouping key depends on various factors, including the
`tax_tag_ids` (tax grids) of the product lines. However, the system
currently processes mixed EPDs before taxes. As a result, when saving at
the end of step 5, EPDs are calculated for `l2`. However, `l2` does not
have tags at this stage, while `l1` does, since it was saved earlier.
This discrepancy leads to incorrect EPD grouping.
opw-3129639
closesodoo/odoo#119226
X-original-commit: 044957eac66bad04aa64dd16488843369cd0833e
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
In the commit a2342f636c, we wanted to
use isFieldReadonly to find out if the groupField field was readonly or
not. Unfortunately, this function was not suitable for this use case.
IsFieldReadonly only works on a record and not on a list. It was a
mistake to move this function to the Datapoint.
In this commit, we will put IsFieldReadonly back in the Record and
not use it to know if the field of the groupField is readonly or not.
As in the past, we will consider that a field is readonly
if its modifiers.readonly is true (we cannot take into account the
expressions to be evaluated because the record is not accessible).
How to reproduce:
Go to a kanban view group on a field with an "attrs={readonly: [...]}
Before this commit:
The view will crash.
After this commit:
No errors occur.
closesodoo/odoo#119144
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
We do not want to allow the creation of lines with zero quantity,
Although we do not know of a standard flow making such requests,
the cart_update routes could accept information such as
* {"product_id": X, "set_qty":0}
* {"product_id": X, "add_qty":0}
If a line with product X already exists, it'll be deleted.
If no such line exists, a new one would be created, which is not
something we want to support.
closesodoo/odoo#118999
X-original-commit: 231c8aa79ddd0b1f4ed47508fa22596ac19daacb
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Paul Morelle <pmo@odoo.com>
This commit replaces a closing </xpath> with a </div>, and also prevents some
potential issues with class overrides for the div.
closesodoo/odoo#119196
Signed-off-by: Arnaud Joset <arj@odoo.com>
The loyalty details on the orders were not useful for the end user.
Now we delete it from the order widget. It also fits the sale behavior where we don't show those informaitons.
closesodoo/odoo#118789
Task-id: 2980232
X-original-commit: bafcda0e8c851fb66b0f6c6cb890cf0bdaad596d
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Introduce an optimised way of reading a graph of data from the webclient.
Before this commit:
When reading data from the webclient it could at most read multiple ids of the same model in one RPC.
This mean that when reading x2many or specific information on many2one, that could only be done after the initial read (when the client knows the ids of the comodels) and model by model.
After this commit:
Introduce methods web_read and web_search_read_unity. Both method receive a specificiation for the fields instead of a list of fields. The specification can request fields from the model, as well as follow relations and request fields for each relations, recursively.
Example of web_read specification for account_move
```python
{'name': {}},
{'date': {}},
{'journal_id': {'fields': {'display_name':{}}}
},
...
{'invoice_line_ids' :
{
'fields': {
'journal_id' : {'fields': {'display_name:{}}},
'move_name' : {},
...
'tax_ids' : {
fields: {
'display_name':{},
...
}
}
}
}
}
```
Result for this example with 2 invoice lines
```python
{
'id': 1234,
'name' : 'invoice name ABC',
'journal_id: {
'id': 999,
'display_name': 'Customer Invoices'
},
...
'invoice_line_ids': [
{
'id': 666,
'journal_id': {
'id': 999,
'display_name': 'Customer Invoices'
},
'move_name': 'a move name',
'tax_ids': [
{
'id': 333,
'display_name: "15% tax",
...
}
]
},
{
'id': 667,
'journal_id': {
'id': 999,
'display_name': 'Customer Invoices'
},
'move_name': 'another move name',
'tax_ids': [
{
'id': 334,
'display_name: "21% customer tax",
...
}
]
}
]
}
```
closesodoo/odoo#119034
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
* = bus, calendar, crm_livechat, hr, hr_holidays, im_livechat, mail_bot,
mass_mailing, privacy_lookup, test_discuss_full, test_mail,
test_mail_full, website_crm_livechat, website_livechat, base
In preparation of splitting discuss and mail modules.
Part of task-3265211
closesodoo/odoo#118354
Related: odoo/upgrade#4553
Related: odoo/enterprise#39661
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The current view replaces the existing groups attribute of the inventory
page in the product template form view with two specified groups (with
only one of these groups being newly introduced in stock).
This commit changes the product view to utilise an xpath that adds the
single new group (stock.group_stock_user), instead of replacing the
content of the attributes.
closesodoo/odoo#119284
X-original-commit: 43c888bb4df26b608ee6b0bedfe41032b40cc883
Related: odoo/enterprise#40101
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
In the Dashboard app, expenses KPI amounts are currently expressed in the
currency they were made in, but with the currency symbol of the company
currency. It also means amounts with different currencies are aggregated.
We want the KPI to be expressed in the company currency and not in the
expense currency.
Note that even with this commit, the amounts are still mixing different
currencies if multiple companies are active
Task 3266092
closesodoo/odoo#119264
X-original-commit: e579ec5b3794d545676accdd23428557b75d05fa
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Calling `fetch` with computed fields will also check that the dependencies
of those fields are fetched, which is good.
This commit adds a check that verifies that all the dependencies are already
fetched before re-fetching them.
closesodoo/odoo#119247
X-original-commit: 7ab724450c9aa29ad6c1739cff1e928d79666dac
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
* = base_geolocalize, calendar, website_crm_partner_assign
Oversight of discuss refactoring. Code is restored into bus module as it
does not depend on any mail or discuss feature.
closesodoo/odoo#119243
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, clickable of a reply-to message mistakenly
extended all the way to the other end of the conversation.
closesodoo/odoo#119228
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In the table of content snippet, both its generated entries and its
content wrapper can be dropped outside of it.
This cannot be allowed because the entries are generated from the
wrapped content that belongs to the same table of content snippet.
If any of them is missing, the feature is broken.
This commit prevents this by hiding the drag handle from the generated
table of content and from the content wrapper.
Note that they can still be moved using the arrows.
task-2752391
closesodoo/odoo#107510
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
When we compare majorless scripts we must ignore the Odoo version.
Otherwise a module upgrade without major Odoo upgrade would fail to run
local scripts majorless scripts. That's what happens for example when
users click the upgrade button of a module.
Example: upgrade from `11.0.1.0` to `11.0.2.0`, with a local `2.0` folder
for upgrades.
```
11.0.1.0 < 11.0.2.0 < 11.0.2.0 -> False (check before this patch)
1.0 < 2.0 <= 2.0 -> True (check with this patch)
```
While still: upgrade from `11.0.2.0` to `12.0.2.0`
```
11.0.2.0 < 12.0.2.0 < 12.0.2.0 -> False (before this patch)
2.0 < 2.0 <= 2.0 -> False (with this patch)
```
closesodoo/odoo#119203
X-original-commit: 84ab74c62a19d08de8b6c7c4e3f3300d7e79bcf9
Signed-off-by: Christophe Simonis <chs@odoo.com>
before this commit:
record = env['model.name'].browse(id)
if record doesn't exist in the database and call
record.translated_field_name = value
Then _get_stored_translation will raise
TypeError: 'NoneType' object is not subscriptable
after this commit:
like write non-translated field, the value can be written to the cache, but not
the database and no error will be raised.
Note: The feature is only for the original ORM 'write', if the 'overriden write'
reads other fields of the non-existing record, a MissingError will be raised.
closesodoo/odoo#119202
X-original-commit: 3ba7ca28a68acccb8eb25f117900c1aa1980264a
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
The new SampleServer class was introduced in c67b9f9907
without dedicated tests. We fix this oversight.
closesodoo/odoo#119188
X-original-commit: 693f7bd74066fa9854db4ecef751f13ec5c7e7a6
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Unsupported operand type(s) for +: 'NoneType' and 'relativedelta'
occur when we create payment terms without a preview date (date_ref).
This is because date_ref has no value.
This commit solves the issue by adding a condition if date_ref is not
available, so it adds current date instead of it.
sentry-4068322613
closesodoo/odoo#119187
X-original-commit: a9f556c0d45c32574c94765462d4b59726fc3f19
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit the "This page" menu sub-section of the website's
menu is displayed as a clickable entry when it is empty.
After this commit any website custom menu sub-section title entry is
hidden if none of its children is displayed.
Steps to reproduce:
- Install website only
- Log in as a restricted editor
- Go to website
- Open the "Site" menu
=> "This page" appears as a clickable entry instead of being hidden.
task-3149639
closesodoo/odoo#119125
X-original-commit: 4625f717bdccd8eea851f74a87a102436627106b
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Issue :
- When mass producing a tracked product, an User Error is raised on validation of splitted MO.
Reproduction :
- Create Serial storable product "Component A", Lot storable product "Component B", Serial Storable product "Finished Serial Product"
- Immediate Transfer 10 * "Component A" and 20 * "Component B"
- Create a BoM for "Finished Serial Product", consuming 1 * "Component A" and 2 * "Component B"
- Create a Manufacturing Order for 10 * "Finished Serial Product" and Confirm :
- Click on "Mass Produce", Set "First SN", Generate all the serials and Apply
- Click on "Produce All"
Task : 3274962
closesodoo/odoo#118592
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
- Enable multi-warehouses (i.e. have a company with 2 warehouses:
warehouse_1 and warehouse_2)
- Set warehouse_2's view_location to a location within warehouse_1
- Check the warehouse_id of a location within warehouse_2
Expected result:
warehouse_id = warehouse_2
Actual result:
warehouse_id = warehouse_1
The issue with this is each warehouse may be configured with their
own routes/rules, therefore a product within warehouse_2 may not
follow the warehouse_2 routes/rules. Note that a nested warehouse
situation like this may occur with warehouses located in different
countries, but products from both warehouses are sold in the same
ecommerce store and `website_warehouse_id` only allows 1
warehouse to be assigned to it
closesodoo/odoo#119181
X-original-commit: 83613b56cadf1a12331db9d4d41ab688d68768e9
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before this commit, content inside chat window could visually fuse
with the header in a way that makes it hard to see the separation
between the header and the content.
This commit fixes the issue by adding a small border below header
when there is some content.
closesodoo/odoo#119173
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce the bug:
- Install purchase, then mrp (in this order)
- Create a storable product “P1”
- route: buy
- Add a supplier
- Add a BoM
- Create a delivery for the product “P1”
- A need is created
- Go to inventory > operation > replenishment
Problem:
An orderpoint is created with the preferred route: Manufacture instead
of buy
As the "Purchase" module was installed first, the override of
the `_set_default_route_id` function will be triggered first, the 'buy'
route will be set in the created order point because the product has a
supplier. Then, the function in the MRP module will be triggered and
since the product has a BoM, the 'buy' route will be replaced by
"Manufacture".
opw-3228971
closesodoo/odoo#119172
X-original-commit: 227d038efbadf25e3a7be7cceedd9159b71162a3
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
- Install Sales.
- Go to any quotation and toggle mobile device mode in the browser.
- Go to Other Info > click in Sales Team field.
Issue:
We stop supporting the 'kanban_view_ref' in newer versions of odoo. So
we won't be able to get proper view.
Solution:
Changed the way we ref the kanban view to use context to get the
referenced kanban view.
Related to #39499
opw-3152174
closesodoo/odoo#116031
Related: odoo/enterprise#39499
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
If applied, this commit will solve the issue of the singleton when there are 2
quants with the same location and same products but one quant with a lot and
another quant without a lot number.
Steps to produce:
- Create one quant with location-1 and without lot number.
- Create another quant with location-1 but with the lot number.
- Create 3rd quant with location-1 with same lot number as step2.
The error will raise in 3rd step as it is not accepting the 2 quants where one
is with lot number and another is without lot number.
see - https://tinyurl.com/2hqrgmwm
sentry - 4024572562
closesodoo/odoo#119152
X-original-commit: 05a7f5c04804423cfc3a833a1b3f0b5eec3fc147
Signed-off-by: Tiffany Chang <tic@odoo.com>
When an orderpoint triggers a procurement for a product and the system does not find the procurement route, it schedules an activity remembering what was the error.
If a normal user without admin access rights, makes an action that triggers the orderpoints, like confirming a MO, the activity schedule is not creating due to an access error on 'write' operation to a Product Template.
So, all activity schedules triggered from an orderpoint should be created without checking access rights.
closesodoo/odoo#119066
X-original-commit: e7de0b7f88ad55f662319aabcc5d989367b8c659
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Use case to reproduce:
- Set "receive good in input and then stock" on the warehouse.
- Set two suppliers on a product. one from a partner (higher priority)
and one from a child partner (lower priority).
- Set the child partner as the vendor on the replenishment report.
- Order a replenishment for the product.
It happens due to an hack that use a field on `stock.move` in order
to temporaly store the partner among the moves until the RFQ.
But this field is a many2one on `res.partner` model and not on
`product.supplierinfo`
`_run_buy` receive a partner and still use `_select_seller` with the
partner in order to find the best pricelist. But it won't use the
specific supplier price list set on the orderpoint.
In order to fix, we don't store anymore the price list partner on the
intermediate move. In run_buy we receive the orderpoint if it's the
origin of the procurement. On the orderpoint the supplierinfo is set.
So we take it from there.
opw-3180945
closesodoo/odoo#119063
X-original-commit: 3cd5b9b7688ef7e6c6fa4fce1c0ad319fb577745
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Mathieu Duckerts-Antoine