Initial issue solved by 3eb06a27da
We keep the test since it ensures that settings can be saved properly.
X-original-commit: 2c1b92f626edaf89c93c3bd96d656aa77c580c69
List of improvements:
Invoice/Bill
- Hide "untaxed amount" section when there is no tax.
- Remove tooltips for tax groups field.
- Remove invoice_partner_icon and set this icon in "Vendor" (in a list view)
Chart of Accounts
- Same views for config bar and regulare one
- By default don't show deprecated accounts and add filter to display them.
- Add some optional fields in list view (taxes, tags, ...)
Dashboard opening balance wizard
- The opening move entry date equals to the opening date - 1 day.
Bank Statements
- Set default order for the list view (by date desc and name desc)
Tax report configuration:
Add 3 new columns for the list view (country_id, code, tag_name)
Add 4 new searchs (name, tag_name, code, country_id)
Task ID: 2048225
closesodoo/odoo#38694
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The method `unlink` checks whether any of the records to delete is used
as the default value of a company-dependent field. The query simply
blows up when deleting several millions of records. The fix consists in
performing the check in batches.
closesodoo/odoo#41331
X-original-commit: 30e8b8f2554e5d16b19f16ea90e3503098dc98a0
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Fix error like "TypeError: {4} is not JSON serializable" when
serializing the session object (e.g. for external storage)
closesodoo/odoo#41360
X-original-commit: e91e38fa4bd12ba9d2027e7778a10252e08b9a86
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
If a module add a state field on another table used by this report,
PostgreSQL will report a:
```psycopg2.ProgrammingError: column reference "state" is ambiguous```
closesodoo/odoo#41350
X-original-commit: 16ae8aed10c72586a3a3e8b7484099263b0d7804
Signed-off-by: Nicolas Seinlet (nse) <nse@odoo.com>
- we would have to set this domain on every actions directing to
products
-we can't set a proper depends_context since the new orm doesn't support
it
closesodoo/odoo#41322
Related: odoo/enterprise#7033
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This context key was used to get the valued quantities. We now have a
`quantity_svl` computed field that does this job. The test is removed,
it was showing that intercompany quants are visible thanks to a context
key but with the introduction of the on_hand filter, it is now useless
(just remove the filter)
tax grouping key from base and tax line that will be used as a key to group taxes together
so both functions must have the same dictionary key. (you can check comment here https://github.com/odoo/odoo/blob/13.0/addons/account/models/account_move.py#L412)
here we have three key (product_id,product_uom_id,quantity) in _get_tax_grouping_key_from_base_line
and only one key (product_id) in _get_tax_grouping_key_from_tax_line
so we get wrong tax calculation
now we remove that extra key(product_uom_id, quantity) because we don't need group by these key values.
closesodoo/odoo#41340
X-original-commit: a758e5eace55bad0c11f8a27ba83e8367d293487
Signed-off-by: Josse Colpaert <jco@openerp.com>
Before this commit, when doing a primary inheritance
the root node of the resulting template was the one of the inherited template
after this commit, the root node of the resulting template is the one defined
on the inheriting template
closesodoo/odoo#39452
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, when a template was inheriting from another
the template mentionned its t-inherit
This has been deemed overkill as the information is irrelevant to the caller
i.e. the caller just wants the template and doesn't care how they've been computed
After this commit, only t-name and attributes not related with inheritance
are disclosed
[FIX]: base: static inheritance propagates other attributes
When doing a inherit in primary mode, the original attributes on the root node of
the inheriting template were not propagated
After this commit they are
At the conception of this feature it has been intentionally thought that
the behavior for static templates should resemble
what is done for ir.ui.view
While keeping the general previous behavior (and this is important)
A little bit of context for ir.ui.view
They are defined as XML's, but end up as python objects
Their meta-data (id, name, inheritance specs...) are thus
present in their XML definition, but end up as part of python objects members
Hence, the final, business, usable arch is free of those meta-data
and is left only with business-relevant dom nodes
The static inheritance feature was backed with those ideas
but inherently encountered the issue that, for them,
the meta-data also end up in the business dom, since
they are at no point considered as plain objects.
Decision has been made, back then, to exclude the root node
that holds the metadata, to be at all targeted by any XPATH
This decision is now challenged as the specs of XPATH should be respected
This commit consequently introduces the root node as any other
It can be replaced, and will be targeted by
`expr="."` or `expr="//NODE_TAG"`
The few attributes that are necessary to define them are kept across
inheritance cycles though.
Instead of hardcoding a domain in the action, we add a field that will
be used to apply the domain. The goal is to be able to define a static
domain in the xml so we'll be able to default on the filter while still
being able to remove it.
Let's consider this usecase:
Physical
| \
WH Subcontracting
| |
Stock 5 units
|
10 units
With the hardcoded domain, we have two problems
- the right part of the tree isn't visible
- the user can add a quant in subcontracting but it will disappear at
the creation since it isn't part of the hardcoded domain.
The complicated part of the domain is the `_get_domain_locations` call.
It will use multiple context keys, the current company and get the
hierarchy of internal locations below warehouses to see what it should
include or not.
To be able to remove a domain, it should be declared in the xml and not
hardcoded in the action. Since the domain is complex, we can't express
it. So we add a computed field "on_hand" and its search method is
overiden to call `_get_domain_locations`.
task-2061825
closesodoo/odoo#40403
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
On a quotation, the forecast report is opened with a default filter on
the warehouse of the quotation. If you remove this filter, quantities
not below warehouses (eg in subcontracting or in a repair location) are
displayed. From the product form, it's not the case, you never see these
quantities. We now add a "warehouse is set" filter that is enabled by
default (so you have the same value in the stat button forecast and in
opening the report) but you can remove it to see all quantities.
task-2061825
In order to see the fields profit_account_id and loss_account_id, we had to be part of the group_account_user which is not available when the module accounting is not used.
Now, to be able to use it when invoicing, we change the group to the group_account_invoice.
closesodoo/odoo#41310
X-original-commit: 164f6ac809473b8c9f31913113249b26b3432fff
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Because of the law of the 1st december 2019, we can't pay with 1 or 2 cents anymore.
We have to round the total price to the 0.05 unit.
If the customer pay without rounding values, it triggers an error.
Before the order is finalized, we add a line with a product rounding to round the total amount.
Task-id: 2035010
X-original-commit: 58477e5503a18cc98fe686f8857233063eb26f4c
A simple test to easily check performance of the reconciliation.
opw 2121587
Co-authored by: François Honoré <francois.honore@acsone.eu>
closesodoo/odoo#41272
X-original-commit: 616c7d4252b30cee0a17ac776a17b626ee815c74
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Task 2046908
Instead of having all the fields duplicated with second_*, we have now a
o2m allowing us to
* have more than 2 lines
* reduce duplicated code
* fix bugs and add features at only one place
We also remove the computation of writeoff and suggestions from the
client side as some code was 4-upled before (twice in in client and
twice in server side). The logic is now only at one place.
closesodoo/odoo#38119
Related: odoo/enterprise#6324
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The only good solution is to set `show_reserved` to `True` to avoid any
kind of weirdness...
This reverts commit eed3171f2f057223c3fbedd95ce6bcde2124f46c.
closesodoo/odoo#41303
X-original-commit: de962efb8a531c69c098ae1706aa5c99d34a808a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
If we do a payment with:
- a currency different than the journal
- the journal currency the same as company currency
=> it fails, because of the constraint on account.move.line:
> The amount expressed in the secondary currency must be positive when
> account is debited and negative when account is credited.
with code:
```
CHECK(currency_id IS NULL OR company_currency_id IS NULL OR
((currency_id != company_currency_id) AND {conditions on balance}))
```
This happens because in this use case, a NON-NULL currency_id means that
the currency is different than the company currency, this was not taken
into account when creating a liquidity line.
opw-2150267
closes#41244closesodoo/odoo#41278
X-original-commit: f9d75e3a5442162538c727eb7e4f111c9b792104
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Usually in a form view, a notebook is not placed within group/s.
Also, using studio we don't let user drop notebook in a group since it
generates issues with the notebook.(See https://github.com/odoo/enterprise/commit/ea5ccd548bb6781e5ccdf76cf11255c6fd6aa3cb)
This commit fixes the issue by moving notebook out of the group and making
the 'payment.icon' form view structure consistent(and properly
editable with studio).
task - 2060330
X-original-commit: c4efe0173478be8b6a643d5fefef4244384ea6c2
When we post multiple draft moves at the same time, the numbering should
be done by starting with the oldest one up to the newest.
closesodoo/odoo#41138
X-original-commit: 5b745eb61377e5b4532f2e370f9b1559a9b66c0a
Related: odoo/enterprise#6975
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
If we have eg. a report with a page break (eg. `Print On New Page`
enabled on a financial report section) the encoding is broken.
The reason is that lxml.html fragments_fromstring function accepts text
string (OK in unicode) or bytestring => the encoding will be guessed (by
chardet library) if guess_charset argument is set to true.
So since we do not pass guess_charset option, the encoding is not
recognized.
In this changeset, we give a text string to the fragments_fromstring
function since it seems that all our input should be in UTF-8.
note: lxml.html itself uses html5lib.HTMLParser parseFragment that takes
a charset argument, but there is no interface through
fragments_fromstring to specify the charset.
opw-2146715
closes#41255closesodoo/odoo#41289
X-original-commit: 1d3d517aad08887970e4ba2d9290e260faacae2d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
If a visitor logs in (and has a visitor_id in his cookie), the partner will be
linked to the visitor. If, after 1 week, the visitor tries to connect again
with a different session (or another visitor_id in cookies), the authenticate
will crash because
* _cron_archive_visitors applies on visitor inactive since at least a week
* there can be only one visitor per partner (sql constraint)
* the visitor linked to the partner is not retrieved (because archived) and
we try to link the partner to a new visitor.
Further than that, if the visitor is archived and the linked partner wants to
login again with a new visitor_id, we should
* reactivate the previous visitor,
* copy history from newest to previous one,
* delete the newest one
Note that last two points were already done before this commit.
Task ID: 2120464
PR #40199Fixes#40077Fixes#40301closesodoo/odoo#41273
Original-signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
X-original-commit: 53a6bed3b5c1ae09be490254ed09f18acbb970c4
Signed-off-by: David Beguin <dbeguin@users.noreply.github.com>
When computing the price of a product through a pricelist item, if the
item was based on anotherp pricelist, the dates and uom weren't given to
the subsequent method call.
As the majority of the calls to those pricelist methods put all their
arguments in the context, it wasn't noticed until now.
Functional example:
Pricelist A:
Rule A1 : 10% discount on Pricelist B, from day 3 to day 6.
Pricelist B:
Rule B1: 5% discount on Sales price, from day 3 to day 6,
Rule B2: 10% discount, from day 7 to day 9.
If today was day 8, the call to pricelist(A)._compute_price_rule(day=5)
would use rules A1 and B2, but should have used rules A1 and B1.
closesodoo/odoo#41295
X-original-commit: df9b113805ed28f274711bb4ba0dd9a2610e5035
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Set a default company since it is mandatory and hidden in mono-company
mode.
opw-2129187
closesodoo/odoo#41259
X-original-commit: ffb6360e87ed8b6fbe5ae19a801230d1f89bc660
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this fix, a QUnit test was wrong (didn't parse)
After this fix, the test actually works and tests something.
closesodoo/odoo#41257
X-original-commit: 3818a7f0df754717a7379dc8341729b508a166be
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Make the domain stricter as well:
* no reason to have / match a token if the payment method is not
electronic
* don't lose the capture mode
* don't remove the company filter though it's probably not useful (as
the journal and payment should already be in the same company so the
check on the token's acquirer's journal should be enough)
The domain used to select the default payment should not matter too much.
Task 2147923
closesodoo/odoo#40959
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Note: the original would only set the domain if
`l10n_latam_use_documents` was enabled but even if the fields are not
shown without that it doesn't make much sense to allow any document
type to be selected when latam docs are *not* being used.
In this revision, the document type is always filtered by available
types and that is only non-empty if we're using latam documents.
Task 2147923
closesodoo/odoo#40955
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce the bug:
- Let's consider a fiscal position FP with automatic detection for customer in your country
- Let's consider two taxes T1 and T2 where T1 is mapped by T2 in FP
- Let's consider a product P with T1 as customer taxe
- Let's consider a customer C in your country with no fiscal position
- Create a repair order for C
- Add P as an add line
Bug:
T1 was set as customer taxe for P instead of T2.
When manually creating an invoice for C with P, FP is automatically
detected and T2 is set.
With this fix, the automatic detection of FP is applied on repair order.
opw:2120595
closesodoo/odoo#40856
X-original-commit: 3810f9d96246fbc21297b71c34704e87288eb77a
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Issue
- Swiss company
- Install Accounting & Studio
- Journals > Customers Invoice
- Communication standard: Switzerland
- Journals > Bank
- Swizz account with CHF ISR subscription number
- Studio > Reports > ISR
Traceback
Cause
If the statement of the `l10n_ch_isr_optical_line` compute
method is False, the value will be `None`.
In the view, we do a foreach on the value which is `None` and
it crashes.
Solution
Set an empty string as default value for the
`l10n_ch_isr_optical_line` field
OPW-2129122
closesodoo/odoo#41247
X-original-commit: a0dc556b0e04c9e89e7f6a8e4e9af045151614f7
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
With the reload from attachment ticked (attachment_use) when dealing with
a single pdf, the attachment's content must be returned without calling _merge_pdfs
in order to preserve the embedded files. Since PyPDF2 doesn't support completely
the embedded files, there are simply dropped with creating a new pdf in _merge_pdfs even
with a single attachement.
closesodoo/odoo#41246
Issue: https://github.com/odoo/odoo/issues/41079
X-original-commit: a8f96bc7f35d047999cd16b7dd03bcddd3c32263
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
`custom_layout` should be set as a context key, otherwise it crashes at
creation because of non-existing field.
opw-2146695
opw-2149726
closesodoo/odoo#41238
X-original-commit: f9837eb08a316965057fe239f434b1c6d5c0196c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
New fields created from `ir.model.fields` view form are copy=True by
default (copy=False in case of One2many) thanks to an onchange but
manually created fields were not (e.g. created from Studio)
Task: 2067885
Do not remove the country set on the company when the state is removed.
closesodoo/odoo#41234
X-original-commit: dfa2a3b7c5d75bfc5a3e5f07171daf373b319ed8
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
steps to reproduce:
-install the manufacturing app
-install studio
-go to manufacturing > click on the studio icon (top right of the window)
> click views > activate the gantt view
you should see a traceback with the following error
"Invalid field 'progress' on model 'mrp.production'"
mrp_production does not have a progress field => removal of the
property "progress" in the view fixes the issue
opw-2144823
closesodoo/odoo#41197
X-original-commit: 31bf253110b9a77ec8d6185b66157cdbfe9e67f5
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
The `session_info` dictionnary is used to bootstrap some JS code client
side (usually in the backend). It includes relevant information, such
as some parameters key for the OdooBot onboarding, the Enterprise
subscription expiration alert, etc. to avoid triggering a lot of RPC
calls upon webclient start.
`session_info` is also called by the remote authentication mechanism
located at `/web/session/authenticate`, which can be used by external
mechanism to obtain a valid session remotely.
Revision odoo/odoo@8a28cc2 introduced the concept of cache keys for
some oft-requested data (such as menus, translations and dynamic qweb
templates) to avoid requesting them on each webclient start, since they
tend not to change often. Unfortunately, it introduced a read on the
ir.ui.menu model that raised an `AccessError` if the authenticating user
was not a member of the `base.group_user` group ('Internal' user type).
While fixing that issue, it became apparent that `session_info`
returns a whole lot of information through this remote connection route
which is entirely unnecessary if not used in the context of a webclient
start, such a currencies, the state of the enterprise subscription, etc.
This commit fixes the access right issue by removing this non-relevant
information from the returned dict (including cache keys) if the user
is not an internal one.
closesodoo/odoo#40770
X-original-commit: 6e99ac2c6cd5ca9af87b4fc7a3a1394359e30b02
Related: odoo/enterprise#6860
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Reproduce the issue
- Load Arabic language
- Install Accounting
- Create an invoice & add credit note
- Switch to arabic
- Click on the "(i)" icon near the total price
The popover is displayed at the other side of the screen
Cause
- RTLcss was reversing the "left: 0" css property to "right: 0"
- The popover configuration was not adapted for RTL
This commit ignore RTL for the popover css "left" property and
configure correctly the JS side
OPW-2146210
closesodoo/odoo#41200
X-original-commit: 88f03f0444a2533b1f6085369af431131da42b54
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
Reproduce the issue
- Load Arabic language
- Install Sales
- Report > Sales
- Switch to arabic
- Click on the pivot view to display the dropdown
The dropdown position is incorrect
Cause
The calculations are based on a `left` value who is weird.
This commit use the mouse X position to compute the `left` value.
OPW-2146210
X-original-commit: d021f4257c87863b75f148c4809f5e2797a1e99f
Nans Lefebvre