In some cases, when billing a received quantity that is already
delivered, the account move lines of Stock Interim (Received) will
not be reconciled
To reproduce the issue:
(Need account_accountant, sale_management)
1. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
2. Create a product P
- Type: Storable
- Category: PC
3. Create and confirm a PO with
- 5 x P at $50
4. Process the receipt R
5. Create and confirm a SO with
- 5 X P
6. Process the delivery
7. Create and post partial bill B01 related to PO:
- 1 x P @ $60
8. Accounting > Accounting > Journal Items
- Group By: Account
- Note: There are three lines in Stock Interim (Receipt):
- [AML01] Debit: 0, Credit: 250 (receipt R)
- [AML02] Debit: 60, Credit: 0 (bill B01)
- [AML03] Debit: 0, Credit: 10 (price diff from B01 because
quantity already delivered)
There is a partial reconcile between AML01 and AML02, AML03 is
not part of this partial reconciliation
9. Create and post partial bill B02 related to PO:
- 4 x P @ $60
10. Accounting > Accounting > Journal Items
- Group By: Account
Error: The lines of account 'Stock Interim (Received)' are not
reconciled while it should
When confirming B01, we try to reconcile AML01, AML02, AML03. In the
reconciliation process, we first sort the AMLs and try to create a
partial reconciliation:
https://github.com/odoo/odoo/blob/01cb7e960f912c4758d30c04653b599937785799/addons/account/models/account_move_line.py#L2282-L2293
Because of the sorting, here is the order of the AMLs:
- [AML01] Debit: 0, Credit: 250
- [AML03] Debit: 0, Credit: 10
- [AML02] Debit: 60, Credit: 0
In `_create_reconciliation_partials`, we consume the AMLs in that
specific order. So, it first uses one credit line and a debit one:
https://github.com/odoo/odoo/blob/01cb7e960f912c4758d30c04653b599937785799/addons/account/models/account_move_line.py#L1863-L1872
(i.e. AML01 and AML02) and creates a partial reconciliation for
theses AMLs. It gives a temporary credit line of 190, but there is
no more debit lines, so the partial reconciliation is stopped (this
explains the note at step 8)
Later on, while posting B02, we try again to reconcile the lines of
Stock Interim (Received)
https://github.com/odoo/odoo/blob/493020b9317a439c0a61a34f37cc92b6779ef633/addons/stock_account/models/account_move.py#L249
At that point, we have three AMLs:
- [AML01] Debit: 0, Credit: 250 (same as above)
- [AML04] Debit: 0, Credit: 40 (price diff from B02)
- [AML05] Debit: 240, Credit: 0 (B02)
Back in the reconciliation progress, we try to get all involved AMLs:
https://github.com/odoo/odoo/blob/01cb7e960f912c4758d30c04653b599937785799/addons/account/models/account_move_line.py#L2284-L2287
It will be used later for the full reconciliation. To get the
involved ones, we recursively get the AMLs implied in the partial
reconciliation of AML01, AML04, AML05:
https://github.com/odoo/odoo/blob/01cb7e960f912c4758d30c04653b599937785799/addons/account/models/account_move_line.py#L2481-L2489
Therefore, because of the first partial reconciliation explained above,
we will find AML02 but not AML03. This is the reason why the full
reconciliation will not happen.
Working on the assumption that the note of step 8 is not a bug (i.e.,
AML03 is not expected to be part of the first partial reconciliation),
we need to provide as much AML as we can when calling the
reconciliation process.
OPW-3040171
closesodoo/odoo#107908
X-original-commit: 3050e23f94c865f9938863f191076f761b80fedb
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
(Received)
In auto-avco, if a user delivers a products before billing its
receipt, the account Stock Interim (Received) will be unbalanced
To reproduce the issue:
(Need account_accountant, sale_management)
1. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
2. Create a product P
- Type: Storable
- Category: PC
3. Create and confirm a PO with
- 1 x P at $50
4. Process the receipt R
5. Create and confirm a SO with
- 1 X P
6. Process the delivery
7. Create the bill B related to PO
8. Set the bill line unit price to $60
9. Confirm
10. Accounting > Accounting > Journal Items
- Group By: Account
Error: The account 'Stock Interim (Received)' is not balanced
(Debit: 60, Credit: 50)
The account entries are:
- Credit 50 related to R
- Debit 60 related to B
There isn't any line for the price difference. Since [1], we don't
generate any price difference layer for the already-delivered
quantities. Before this commit, a layer was generated and posted on
account-side:
https://github.com/odoo/odoo/blob/a5b985e8449a1e858c3fb9a0a90a6d203e16f739/addons/stock_account/models/account_move.py#L68-L69
But, as explained in [1], we should generate the price diff layers
only for the remaining quantities, otherwise it would lead to some
errors on both stock and account side. That being said, we still
have something to do with the price diff related to the out
quantities. This is what this commit is about. In such case, we
generate some journal entries:
- we credit the account 'Stock Interim (Received)' with the price
diff (the account is then balanced)
- we debit the account 'Expenses'
To do so, we:
- Bring back the method
`_stock_account_prepare_anglo_saxon_in_lines_vals` from [2]
- Fix that method because both fields `analytic_account_id` and
`analytic_tag_ids` do not exist anymore [3]
- Update it so it behaves as described above
Note 01: in the steps, we have removed the case 'Receive, Return and
Receive again'. Such a flow breaks the whole accounting and would
not work with some other features. Therefore, we consider such a
flow as invalid (the user could rather create a new purchase order
to receive the quantities again)
Note 02: This behaviour is not supposed to work with the kits. This
commit prevents the lines to be posted in such situation. Suppose
the flow is in a "standard" order (PO, Bill, SO), we also do not
create layers for the price difference:
[1] 18912b05239e6fc5dab26ec4c930f9080882d127
[2] 35d6c58f86
[3] odoo/enterprise@a1eaf200d0
OPW-3040171
OPW-3071238
X-original-commit: 84733fb89faffe2480def97f076633056e16572f
Part-of: odoo/odoo#107908
Steps to reproduce
- Install Accounting
- Create user and employee, "user_acc", with Accounting-Accounting and no Expense rights
- Take the expense in "To Submit" state for the employee different than user_acc and create report
- Save the report.
Bug - We get the error that required field 'name' is not set and expense lines disappear.
task - 3099142
closesodoo/odoo#107903
X-original-commit: c5765be58dcdb3f6d766e6ce409a6e0f8a82e45b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Computing the recurrences of a task repeating every X months until a
certain date generates too much dates
Steps to reproduce:
1. Install Project
2. Go to Settings > Project > Tasks Management and enable Recurring
Tasks
3. Open any project in the Project app and create a new task then edit
it
4. Enable the Recurrent field of the task
5. In the Recurrence tab, edit:
- Repeat Every: 6 Months
- Until: End Date: one year from now
6. The recurrence message says there are 11 tasks but there should only
be 2
Solution:
Generate the recurrences until the `repeat_until` date is reached if the
`repeat_type` is 'until', otherwise generate as much recurrences as the
count
Also relax the constraint on the `repeat_day` and `repeat_until` to not
raise an error if `repeat_until` is the last day of the month
Problem:
The recurrence of a task with `repeat_unit` month and `repeat_interval`
different than 1 with a `repeat_type` until creates too much tasks,
exceeding the `repeat_until`
opw-3076593
closesodoo/odoo#107910
X-original-commit: 236b383fd9d1ad6a5d39d8c4232b49864ec19b37
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Some demo mass mailings are currently defined as being "in queue" in demo
data. This means they are about to be send by the mailing cron.
However we don't want demo data to send emails as
* most of those emails are fake (e.g. targeting example.com);
* real emails should not be sent (e.g. having by mistake a real email that
will be spammed);
* statistics resulting from those emails will not have any wow effect;
* on SaaS this consumes email quota, and produces quite a big volume of
unnecessary emails when people try the 16.0 version;
It is better to either have demo data of mailings done with traces, or keep
other mailings in draft. Otherwise the cron will send them. Flagging those
mailings is difficult, as emails are sent asynchronously and not during
install or update.
Even if this may lessen wow effect of some kanban view, better move mailings
currently "in queue" to "draft".
closesodoo/odoo#107904
X-original-commit: 0e11f4926be1800fc2b58feedcd81df24720ec19
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Cleanups and fixes/improvements extracted from another task
on the settings of sale.
* indentation
* code simplification
* privatize method not meant to be called by rpc
* double quoted strings for strings shown to users, single quoted for
technical strings
* translate onchange warning message
closesodoo/odoo#107897
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce the issue:
- Accounting > Configuration > Journals
- Click on Journal
- View metadata of Journal
Bug:
Even if no modification has been made to the journal, it marked current time
in Latest Modification By/Date
opw:3089551
closesodoo/odoo#107875
X-original-commit: 47999e7b1c9a52059f84abaafeac388f2991a621
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
in account and hr module's manifest file non existing image path is specified in images key. removing this images key from manifest and remove empty images key from l10n_latam_check module
closesodoo/odoo#107346
Related: odoo/enterprise#34711
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Steps to reproduce the bug:
- Create a BoM with components
- Archive one of the components
Problem:
No warning is displayed for the user to inform that the product is
used as a component in a BoM
opw-3089104
closesodoo/odoo#107863
X-original-commit: 9b7c416387d93507b6f750aba58ad6233a59d512
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
**Issue:**
- Install CRM.
- Change language to French.
- From CRM, open a lead that has `Revenu espéré` thousands as value, e.g. 10 000,00.
- Try changing `Revenu espéré` by deleting one of the thousands digit.
E.g. 10 000,00 -> 1 000,00
- BUG: The modified value is not understood by the system.
**Solution:**
This is because the thousands separator from the French language is nbsp.
Coincidentally, the parsing logic assumes that the separator between the
currency symbol and value is also nbsp. So when inputting `1 000,00`,
the parsers thinks either `1` or `000,00` is the currency symbol.
We concluded that it's better to be less restrictive when parsing
monetary values. So, instead of making sure that the current input's
currency is compatible with the currency of the the field, we just
strip the non-numeric characters from beginning and end of the input
without validating the currency symbol, then parse the remaining
string as float.
This leads to a more user-friendly monetary input fields such that
inputting "DOGE 1,000,000.01" in a "$" monetary field will be
parsed as 1000000.01. NOTE that *no* currency conversion is performed.
**Minor breaking change:**
The second parameter `options` of the `parseMonetary` function is now
removed. Any existing use of that parameter is just ignored.
closesodoo/odoo#107862
X-original-commit: dc27f1f4c039bdbf84c55a4fb5364c6398c45949
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
**Issue:**
When the thousands separator is "nbsp" and the user inputs a value
that is "1 234", the parser will crash because the thousands separator
is different from what is manually inputted by the user.
This is problematic because when typing, it's very difficult for
users to enter "nbsp" character in their input.
**Solution:**
This change proposes that if the thousands separator is a whitespace,
we consider all whitespace characters from user input as thousands
separator. As a result, even if the thousands separator is "nbsp",
the system will successfully parse "1 234" as 1234.
X-original-commit: bffddcf015da9cf514fc25cc7f839e923e470d94
Part-of: odoo/odoo#107862
**Issue:**
- Set the decimal point to "," and the thousand separator to ".".
- In a float or monetary field, enter "=1.000,1+2.000,2"
- BUG: It's evaluated to: 30003
**Solution:**
Problematic evaluation steps:
```
-> parseNumber("=1.000,1+2.000,2")
- thousands separator are removed and decimals are converted to "."
so the string becomes "=1000.1+2000.2".
-> parseNumber("1000.1") + parseNumber("2000.1")
- since "." is the thousands separator, it will be removed
(replaced by empty string)
-> 10001 + 20001
-> 30003
```
Because the main parser `parseNumber` is recursive in nature, we
need to make sure that the logic that removes the thousands separator
and replaces the decimal point to "." is not called in the branch
that evaluates an input expression.
With this change, the new evaluation steps are:
```
-> parseNumber("=1.000,1+2.000,2")
-> parseNumber("1.000,1") + parseNumber("2.000,1")
-> 1000.1 + 2000.1
-> 3000.3
```
X-original-commit: 91eb5c40ce898428fb15d945d70510b92e9ebb03
Part-of: odoo/odoo#107862
closesodoo/odoo#107856
X-original-commit: 409fc809bafec2507342534bcdf4810ebffe9228
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
In the QUnit type definitions, there is a QUnit namespace and a QUnit
interface. When using a jetbrains IDE, it is confused between the two
and thinks the global QUnit is the namespace.
This means that it can't resolve QUnit.test, QUnit.module, etc
This fixes this issue by disambiguating between the two.
X-original-commit: 26dc799f841e51a6d57d427e095b662a45bc7e5a
Part-of: odoo/odoo#107856
Improving:
- Chart of account
- Tax report
- Fiscal position
- Translation
Task-id: 2753362
Signed-off-by: Maximilien La Barre <malb@odoo.com>
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#99450
Related: odoo/enterprise#31003
Signed-off-by: William André (wan) <wan@odoo.com>
Currently, when the vehicle is assigned, it is checked from the first contract date, now it
will be checked from the order date
In this Commit, We added order date field in fleet vehicle
task-3054981
closesodoo/odoo#107073
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In this version of the tooling, the prettier files do not exist anymore.
We don't want to check if the files have changed, it will always be true
and trigger a reload of the tooling.
closesodoo/odoo#107825
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Before this commit, it was possible to define a <widget/> in the arch of
an x2many in list mode. But this was not supported in normal list views.
So in order to unify the api, we decided to support in the list
view as well.
In a future commit, we plan to improve the widget api to receive only
the necessary props.
closesodoo/odoo#107811
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Journal Items menu was not visible out of debug mode, now it is visible
Closes PR #105704closesodoo/odoo#107668
X-original-commit: fbedc97a5479bace8b23122fc423abdeb2c1757a
Related: odoo/enterprise#34876
Signed-off-by: Laurent Smet <las@odoo.com>
Before:
In the kanban card of Bank/Cash journals
- Clicking the title of the journal opened recon widget (kanban) now it opens BSL list
- Clicking on operations opened recon widget (kanban) now it opens BSL list
- Journal Items view was opening recon widget (kanban) now it opens Journal Items
In bank transactions tree view:
- `Match` button was always visible, now it is visible if line is not matched, otherwise it renames to `View`
Closes PR #105704
X-original-commit: 178991eafdadfd955a7aa68bdecf94a39ec8e2fe
Part-of: odoo/odoo#107668
update the module name of l10n_ma. Morocco is the real country name and currently upon searching with country name, app is not listed.
closesodoo/odoo#107650
X-original-commit: f6438dbca6782401f1b23497271398210b113df4
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Purpose:
When a list view with searchpanel is empty, the searchpanel is completely
empty and white, and it's unclear what it's for. Make it obvious by
displaying an empty state. This will typically happen in some views when
you have no data or don't have the groups needed to show filters.
Spec:
Display the following paragraphs with the bs classes "small" and "text-muted":
"No quick filter available."
"Update the filters in the search bar to display more records."
"Quick filters will become available if the records shown can be filtered."
closesodoo/odoo#107379
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Add edi_format "A-NZ BIS Billing 3.0" used in Australia and New-Zealand.
This format is derived from Peppol BIS Billing 3.0.
task-2994014
closesodoo/odoo#103056
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
From the commit 2ab231bd7af609a751ed8168cc094dfeb1012eda
We introduce a error in the path to read Linux file
In this commit we correct the access to the file
which is in the "home" of the raspberry
closesodoo/odoo#107779
X-original-commit: e427d0a2147896aa4311488ebc13f45b84cb330c
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
There are three rationales behind this change to set USD as default
currency and to enable it in the demo data, from the beginning.
With a demo database, before this revision:
1. On runbot, with all modules installed, it's already USD the default
company currency. It's only when you install a module not depending
on account that it's EUR the company currency by default (e.g. CRM)
2. in the base demo data,
the company is set in the United States but with the currency EUR,
3. before installing account, the company currency is EUR,
after installing account, the company currency is USD,
this is due to the fact as the company is in the United States,
the US Chart Of Account is installed, switching the company currency
to USD.
4. when you install a demo database with a module not depending on
account, you are left with a database without any active currency,
and the monetary fields therefore do not show any currency.
For instance, install only CRM with demo,
you have no currency symbol before or after the expected revenue,
which is not the best user friendly experience.
On runbot you do not feel it because all modules are installed,
therefore with account installed, which activated the USD currency.
Additional weird thing with point 2.:
- Unit tests in modules not dependent on account with the
post-install tag had to handle this sudden change of currency change
before and after installing account.
For instance, when running their unit tests with only their module,
but not account, the company currency is EUR,
but when executing the same unit test with all modules installed,
the company currency is USD.
The unit tests had to handle this sudden change within the unit test,
for instance by setting a 1.0 rate for their own company currency,
which shouldn't be the case: the rate of your own currency should
always be 1.0.
closesodoo/odoo#107113
Related: odoo/enterprise#34613
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Steps to reproduce:
-install l10n_sa_invoice module
-switch to a company in Saudi Arabia (SA company)
-create and print an invoice with a product that has arabic translation
Bug:
When adding a product and the Arabic translation.
If we add an internal reference it is added to the template,
Odoo directly concatenates this with the product name.
The result is the product name being duplicated.
Fix:
display line name and add the translation if it's different
opw-2829934
closesodoo/odoo#107798
X-original-commit: ad585bc41f49d047c150ceb9dc88bd9859fa046b
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
`website_sale` module has custom handler for form submit event. That handler
ignores `noFuzzy` attribute. As result, adding `data-no-fuzzy="1"` to
`input[name=search]` works everywhere, but not on shop product list pages.
STEPS:
1. Settings > Technical > Views > website_search_box_input & website_search_box > Code in data-no-fuzzy="1" into the <input> tag
2. Go to Website >.Shop > Customize > Enable ecommerce categories
3. Search for a product on the main shopping page and enter > Observe the URL > There is no noFuzzy param
4. Go to any product's page on the website > search for a product through the search bar and enter > Observe the URL > there is a noFuzzy param passed
opw-3051319
closesodoo/odoo#107771
X-original-commit: 1df3b14f86bada2e2cf278d2b4e591996e9e8db8
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Steps to reproduce:
- Go to Request for quotation.
- Make any search that retrieves no values. (So we get the "no request
for quotation found." message)
- Open Filters dropdown menu. (or Any menu which lenghts will be over
this message)
Issue:
The dropdown menu will be under the message, the message is overlaping
the dropdown menu when it shouldn't be.
Solution:
We need to set the message to `position: relative` instead of
`position: static` so we take into account the right z-index for the
message.
opw-3080171
closesodoo/odoo#107409
X-original-commit: 47a6a555c5bcedffdfda7586ecbe4311d2a45e5f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>
Before this commit, the color badge for draft and sent quotations had
the same color. Same as the line color in list view.
After this commit, color badges and lines are different between draft
and sent quotations.
task-3010707
closesodoo/odoo#106843
Related: odoo/enterprise#34188
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When the url redirects to an anchor on a website page, the page must
scroll correctly to the section. This commit allows to do that by taking
into account the size of the navbar. The bug is visible by following
those steps:
- Drop a text - image block on a page
- Drop a picture block under text - image block
- Create a link to target the picture block
- Put link to block picture in the "Learn more" button
- Save
- Right click on the "Learn more" button and open link in a new tab
=> The page is not scrolled correctly to the picture block.
Note that the bug is not present if the header has scroll, disappear or
fade out as scroll effect.
task-2818629
closesodoo/odoo#92777
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Follow-up reports were previously not handled by the commit fixing
invoices. This commit aims to fix that.
closesodoo/odoo#107787
X-original-commit: 768cfbe095cd6757771dcc683637fd510b0fbddb
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Solan Delvenne (sode) <sode@odoo.com>
The kanban cards did not take the class
oe_kanban_color.
This is because it was set on the child div
instead of the parent one.
opw-3069024
closesodoo/odoo#107778
X-original-commit: 9078761d10289446cfd3881e9df9061075441440
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
STEPS: Create a Pricelist with price rule discount-based on parent product
category. Result: the price rule discount is not applied if the product is not
directly attached to a parent category.
Fix it by correcting domain in `_get_applicable_rules_domain`.
Also, update tests: use parent category in the pricelist.
https://github.com/odoo/odoo/commit/dc8db07ba718a2de845455efc6e265213537eedf
opw-3080836
closesodoo/odoo#107769
X-original-commit: ce44c045f6b75fa64962625baad322632a9c2979
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The demo data were assigning random res.partner as home_address_id for
some employees, this is no longer required since #98027.
closesodoo/odoo#107767
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When a record is `forcecreate=0` and a reference of one of its fields is missing, the update of the corresponding module fails. In this case, we can skip the creation of this record.
An example of this issue is this [record](https://github.com/odoo/enterprise/blob/6411ae071ace980834befeb8040c94b1a05c8034/documents_account/data/data.xml#L17) in `documents_account` module (enterprise) when the reference of this [field](https://github.com/odoo/enterprise/blob/6411ae071ace980834befeb8040c94b1a05c8034/documents_account/data/data.xml#L20) is missing.
This can be reproduced as follows:
1. Create a DB with `documents_account` module
2. Uninstall `documents_account` module
3. Remove `documents.documents_finance_status`
4. Reinstall `documents_account`
```
Traceback (most recent call last):
File "/home/ayman/src/odoo/15.0/odoo/tools/convert.py", line 680, in _tag_root
f(rec)
File "/home/ayman/src/odoo/15.0/odoo/tools/convert.py", line 567, in _tag_record
f_val = self.id_get(f_ref)
File "/home/ayman/src/odoo/15.0/odoo/tools/convert.py", line 663, in id_get
res = self.model_id_get(id_str, raise_if_not_found)
File "/home/ayman/src/odoo/15.0/odoo/tools/convert.py", line 669, in model_id_get
return self.env['ir.model.data']._xmlid_to_res_model_res_id(id_str, raise_if_not_found=raise_if_not_found)
File "/home/ayman/src/odoo/15.0/odoo/addons/base/models/ir_model.py", line 1943, in _xmlid_to_res_model_res_id
return self._xmlid_lookup(xmlid)[1:3]
File "<decorator-gen-35>", line 2, in _xmlid_lookup
File "/home/ayman/src/odoo/15.0/odoo/tools/cache.py", line 90, in lookup
value = d[key] = self.method(*args, **kwargs)
File "/home/ayman/src/odoo/15.0/odoo/addons/base/models/ir_model.py", line 1936, in _xmlid_lookup
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: documents.documents_finance_status
```
closesodoo/odoo#107766
X-original-commit: 2e4f0667397d2d6670df50b9088fa9c23f1f9f5a
Signed-off-by: Christophe Simonis <chs@odoo.com>
Have a kanban view by default grouped by a date field, with a granularity
eg: "date:month".
Have no data so that the read group returns with only the groups for the range (fill temporal).
Those groups should have a count of zero, triggering the sample server to make up data.
Before this commit, there were multiple crashes basically because the groupby written
as field:granularity was not handled at least in the case were groups are returned by the server.
That is, from the sample server perspective, groups are reused and records are just made up
matching those groups.
There were two issues in fact:
- the groupBy with granularity (eg: date:month) was not properly handled, sometimes not splitting
the field name and the granularity, sometimes splitting those up where it should not.
- since the RelationalModel's groups are re-used verbatim by the sample server
(which still needs to return what the real web_read_group would), the "__range" data was missing,
since it had been transformed by the RelationalModel after the real call to web_read_group to the server.
After this commit, this use case is supported.
opw-3063067
closesodoo/odoo#107529
X-original-commit: 060b237f3caac5241130915b41a34aab7d28f4cb
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
When printing labels in a `ready` picking, if no quantities are set it
will only print the reserved quantities as labels.
Then, if a product has no reserved quantity, it will not have any
move_lines. Which means its initial demand won't be able to be fetched,
and the default behavior will be used, which is to print a single label.
By giving the moves instead of the move_lines to the wizard, we allow to
fetch for moves that have no reservation and print labels correctly
using their initial demand if no reservation is found.
The standard behavior once quantities are set remains untouched.
closesodoo/odoo#106414
Related: odoo/upgrade#4091
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Commit [1] introduced the creation of a website in the tests, but
wrongly set `user_id` to the current environment user.
It doesn't make any sense as this field is supposed to hold the website
public user, which is not a real user and is supposed to be a public
user, as the field name hints..
On top of that, the current environment user (the demo user for tests,
which is wrongly set as the website public user) is then used to login
into the website, which is then making things even more weird/wrong: you
are not supposed to login with the public user (which is not really a
public user here but still marked as the public user from the website).
It was preventing the fix from this same PR (see previous commit) to be
working, as it was making this tour crash.
Not setting the `user_id` property will simply let the system create one
for you (a real public user..).
[1]: https://github.com/odoo/odoo/commit/3611aaf0983b3d25822022ebeddd781f6d082bf7closesodoo/odoo#107759
X-original-commit: 68fc99cf944090a37ee2d392990f39adb4899076
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
One can very well select a "auth=user route" as homepage for his
website, like /my.
There would then be an issue with such an URL being set as homepage:
- As the user landed in the homepage controller which is auth=public,
the system will add the public user as env user (see
`_auth_method_public()`).
```
@http.route('/', type='http', auth="public", website=True, sitemap=True)
def index(self, **kw):
```
- Then, that controller will reroute to the homepage url (/my). The
request.httprequest.path will now be /my
- Then, that controller will recall the dispatcher stack:
`request._serve_ir_http()`
- From there, this call won't fail as it should because the user is
considered as logged in as it went already through the
`_auth_method_public()`, adding the public user as env.user.
`_auth_method_user()` won't raise its error.
- The /my page will be rendered despite not being logged in.
Once the user land on that page, the system will actually detect him as
logged out on a page supposed to be accessed when logged in.
It will then:
1. Show a toaster to inform the user
2. Auto reload the page
As the current URL is still `/` (due to the reroute and not a redirect),
the same flow will happen again, and again, looping forever.
--------
Note that accessing /my directly won't be an issue, as it won't go
through the homepage controller (which is auth=public), so there won't
be a user_id set on the env (the public user), meaning that the dispatch
layer will reject the access and raise an access error (through
`_auth_method_user()`.
Also note that the same behavior will occur when going through the first
menu fallback mechanism:
- if the user didn't setup any homepage_url
- and deleted his / website.page
- and his first website menu is /my
In that case, it will go through the first menu redirect fallback, which
will be working fine (as it's a redirect and not a reroute).
With both those 2 flows (going through redirect), the user will
correctly land on the login page (which will redirect to /my once logged
in).
------
Finally, the other solution would be to prevent such a configuration
(/my as homepage_url) but it was not easily doable (if doable at all),
see https://github.com/odoo/odoo/pull/99100#discussion_r963055251
------
A test is also added and over the more complexe case (which should cover
everything):
- With /my as homepage_url
- With the / website.page deleted
- With /my as first menu URL
-> Accessing / as public user should:
1. Reroute to /my (because of the homepage_url set to it) which
should fail now thanks to this commit
2. Since the reroute / re-serve failed, it should reach the
"first menu fallback" mechanism, which is also /my
3. That fallback should be a redirect, not a reroute, so the user
should actually land on the login page
4. Once logged in on that page, it should properly redirect to /my
opw-3077339
X-original-commit: 4f5899f769266edc27a0b2d812df092b95f43c71
Part-of: odoo/odoo#107759
Commit [1] improved the "sanitation" of this field for special
character. For instance, when copy pasting the following terms:
| Input | Before | After |
|-----------------|------------------|-----------------|
| fée d'été à 40€ | f-e-d-t-40- | fee-dete-a-40 |
| Nội dung có Dấu | n-i-dung-c-d-u | noi-dung-co-dau |
But it actually came with a bad behavior which was not noticed: it
prevents to type `-` at the end of the input, which sounds good but is
not.
Indeed, when typing `a-word`, you will type `a` then try to type `-`
which won't work as considering a (forbidden) trailing slash, even if
you actually want to type something after.
This commit allows trailing slashes again, it's not a big deal and one
can remove it if he wants to.
[1]: https://github.com/odoo/odoo/commit/bb43d4dbb5745be84f0f9462e768989e50607bea
opw-3075419
closesodoo/odoo#107746
X-original-commit: bb43e343c0ec823dad8b102a81945b4a05a7af85
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
install purchase_requisition module, and create an RFQ in db, check the alternatives tab in the notebook, currently the button Create Alternatives will not be visible unless user click the save button manually. button no longer needs to be hidden when creating a new PO since v16 added in the auto-save feature
closesodoo/odoo#107733
X-original-commit: a6a830e89c724f993b930442573d8d0c4e692b07
Signed-off-by: Tiffany Chang <tic@odoo.com>
This commit adds a new Unselect all button displayed when at least two
records are selected in a list view. This button appears near other list
buttons. Once clicked, the selected items are deselected and the button
disappears.
Some list view tests have been modified since that change now adds a
button in cases where it was not expected before. Those tests now verify
the behavior when the button is clicked.
task-3081101
closesodoo/odoo#107294
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The icons of the enterprise applications in the community apps list are
not updated with the new icons.
This commit update the old icons with the new ones from the enterprise
version.
Note: some of the app in the apps list should be deleted as they're
not in the enterprise version anymore:
- Android & Iphone (using same icon as CRM)
- MRP II
- Website Version
- Website Form
task-3062514
[FIX] web: updating community icons
closesodoo/odoo#106587
Signed-off-by: Julien Castiaux <juc@odoo.com>
Adrien Widart (awt)