The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
Before this commit
==================
When we post a Customer Invoice by adding 2 products first one has a positive
unit value and the second one has a negative unit value than the wrong JSON
is generated.
The issue happens because of abs method converts the negative value into a positive.
After this commit
==================
In this commit, we are using the sign amount instead of the abs method.
Effected from this PR https://github.com/odoo/odoo/pull/99401closesodoo/odoo#104876
X-original-commit: 99b99bc672a54665b59efaa3a4e696f6250065c3
Signed-off-by: Josse Colpaert <jco@odoo.com>
Due to the deprecation of t-esc to the unique use
of t-out in the rendering template, this replace
every usage of it and ensures everything continues to
work as inteded. Removing deprecation warnings
polluting terminal
deprecation commit: odoo/odoo:9ce5bc8881ae06b613ef61eb07453b224f62bae6
closesodoo/odoo#103731
Related: odoo/enterprise#33037
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit the neutralize system introduced in v16 was using ORM
methods in order to change appropriate records. Although flexible, this approach
could lead to call some methods with side effects while neutralizing
(eg: overloads of write).
This patch converts the neutralize system to a safer "inert" SQL based approach
by migrating the generic method _neutralize to SQL files exposed in the
data folder.
Task id: 2961687closesodoo/odoo#102792
X-original-commit: e5dbded9bb363351feff7ca8a56c7f8a6860f492
Related: odoo/enterprise#32580
Signed-off-by: Fabien Meghazi <fme@odoo.com>
Before this commit
==================
before this commit, it will raise the error when submitting EDI
because the tax report line does not exist and it will be removed
from this PR #99401
After this commit
=================
no error will be raised and it will get related tag_ids
closesodoo/odoo#101988
X-original-commit: 9a60822ae9227d7fa815b06cb0a26629ec075e1e
Signed-off-by: Josse Colpaert <jco@odoo.com>
Add a new method `_get_move_applicability` allowing to trigger the EDI on any journal entry, using the custom functions you want.
closesodoo/odoo#101985
X-original-commit: 0e5626ca5126e6fea7fb95b694229948540764d7
Related: odoo/enterprise#32212
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
The current taxes computation method defined in account_edi has been moved to account on account.tax to be usable on any models.
closesodoo/odoo#99401
Related: odoo/enterprise#30967
Signed-off-by: Laurent Smet <las@odoo.com>
Before this commit
==================
Error not raise In E-invoice(IN) config when authentication is failed
After this commit
=================
Error raise in E-invoice(IN) config when authentication is failed
closesodoo/odoo#99148
X-original-commit: c01b26d3391b53468c3bee8ff0117e55f5115943
Signed-off-by: Josse Colpaert <jco@odoo.com>
This commit adapts account's model to the new report engine introduced for v16, and updates the data files accordingly.
account.report model is now declared in community, together with the other models used by the reporting. This is done so that the tax tags can properly be created by the tax report and used on tax templates. All the actual computation logic stays in enterprise.
See enterprise commit for full details.
Task 2524389
Part-of: odoo/odoo#94125
Before this commit, when we create an export Invoice ( foreign customer )
without shipping details and processing the invoice, the system asks for
mandatory to provide details of shipping, which are not compulsory to
generate an E-Invoice in India.
After this commit, the system will proceed with E-Invoicing in case of
export without shipping details on the invoice form.
closesodoo/odoo#98737
Task-id: 2948375
X-original-commit: d2d68fcc6c019847b552f3a61b6fabebeb13a354
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before this commit, not able to submit overseas invoices to the portal if the
delivery and billing address are different, the same overseas invoice can be
submitted to the portal if the delivery and billing address are the same.
After this commit, we can able to submit an e-invoice even if the delivery and
billing addresses are different.
Task-id: 2871478
X-original-commit: c38395b08f08f333e8252f79588c7661dfa3b965
Part-of: odoo/odoo#98737
TLDR:
* invoices are implemented using computed methods instead of onchange
* the synchronization only happens when switching tabs in the Form view
to improve perfs.
_______________________________________________________________________
The whole engine of the synchronization of Invoices to the Journal
Entries has been refactored
* by using computed fields instead of onchange functions
* by synchronizing only from invoice to journal entry in `create` and
`write`
* by saving when switching tabs on the Invoice form, to synchronize
before showing the values
This comes with numerous advantages:
* no need to call the onchange methods manually
* no need to use the Form emulator to build invoices (i.e. EDI, OCR,
intercompany, ...)
* the performance for invoices with many lines improves drastically, going
from 2 minutes to 4 seconds to create an invoice with 500 lines
* the model is more declarative, we can now see how the values are computed
instead of having the values being copied from various places.
* remove the hack in `onchange` that disabled the recursivity of it,
which was unexpected and needed to be managed manually in all the
onchange methods
This means that:
* Some fields need to be exclusively computed on journal entries values
or invoice values, more specifically the Tax Summary widget.
It is now
- computed from entry lines, when opening the view
- computed from invoice lines when changing those, because the tax lines
will need to be recomputed anyways, erasing previously set values
- set with an inverse function when saving; after the sync has been done
* Some possible operations previously possible have been dropped.
(i.e. look at the removed test test_in_invoice_line_onchange_accounting_fields_1)
This is because such a behavior was undefined (how is changing the balance going
to affect the unit price? How is the amount currency going to affect it?)
_______________________________________________________________________
Implementation Details
----------------------
The "dynamic lines", meaning the payment terms and the tax lines are now
only created in the `create` and `write` functions.
In order to reduce code duplication, it has been implemented using
context managers used in both `account.move` and `account.move.line`
These context managers help comparing the values before/after, acting
like a local `onchange`, but getting benefit from the dirty flags from
the `compute` dependences.
This is relying on computed fields on the move (`needed_terms`) and on
the lines (`compute_all_tax`) which contain the values needed for the
related move.
Depending on the needed values and the existing values (`term_key` and
`tax_key`, respectively) the context manager will determine what needs
to be created/updated/deleted.
Some related changes are to produce a `dict` instead of a `str` for the
`tax_totals` (previously `tax_totals_json`) fields, by simplicity to
reduce the complexity of IO, and simplicity of debugging, because the
logic of the field needed to change (cannot be computed at the same time
anymore since it needed the lines to be synced)
By simplicity, and also because it makes more sense, some boolean fields
have been merged into `display_type`:
* `is_rounding_line`
* `exclude_from_invoice_tab`
* `is_anglo_saxon_line`
The `price_unit`, `quantity` and other "invoice fields" are now not set
anymore on lines that are not product lines since it didn't make any
sense to have it.
Performances
------------
You have to keep in mind that a simple `create` didn't compute a lot of
fields, for instance not taxes were set, no payment terms,...
Now it does.
```python
import random
from timeit import timeit
from odoo import Command
domain = [('company_id', 'in', (False, self.env.company.id))]
products = self.env['product.product'].search(domain).ids
partners = self.env['res.partner'].search(domain).ids
taxes = self.env['account.tax'].search(domain).ids
def create(nmove, nline):
self.env['account.move'].create([
{
'move_type': 'out_invoice',
'partner_id': random.choice(partners),
'invoice_line_ids': [
Command.create({
'name': f'line{i}',
'product_id': random.choice(products),
'tax_ids': [Command.set([random.choice(taxes)])],
})
for i in range(nline)
]
}
for j in range(nmove)
])
# After | Before
print(timeit("create(1, 1)", globals=globals(), number=1)) # 0.11 | 0.09
print(timeit("create(100, 1)", globals=globals(), number=1)) # 2.76 | 2.50
print(timeit("create(500, 1)", globals=globals(), number=1)) # 14.56 | 12.34
print(timeit("create(1, 100)", globals=globals(), number=1)) # 1.03 | 5.52
print(timeit("create(1, 500)", globals=globals(), number=1)) # 3.99 | 125.02
print(timeit("create(50, 50)", globals=globals(), number=1)) # 19.44 | 79.55
```
Another metric that can be used is running the test suite with
`--test-tags=/account` (only `account` installed)
* before: 404s, 267127 queries (366 tests)
* after: 318s, 232125 queries (362 tests)
Why this commit title?
----------------------
Someone told me that this was the perfect way of naming your commits.
c04065abd8
task-2711317
closesodoo/odoo#96134
Related: odoo/upgrade#3715
Related: odoo/enterprise#29758
Signed-off-by: Laurent Smet <las@odoo.com>
Before this commit:
===================
unit price calculation give error ZeroDivisionError: float division by zero for more details https://pad.odoo.com/p/r.c871c2581c415b13b0455a192ad0619d
After this commit:
==================
No error and set unit price,total amount before discount and discount amount if 100% discount or zero quantity is there
closesodoo/odoo#93027
X-original-commit: 60047761e592e9621650d65ac6ac1911f853141a
Signed-off-by: Josse Colpaert <jco@odoo.com>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
set test env and remove username,password,token and token validity
so call never go to production server from test db
closesodoo/odoo#90084
X-original-commit: 955a83f9e773ad1bf7ce0aa4a834d9ca833cd580
Signed-off-by: William André (wan) <wan@odoo.com>
we find some bug when backporting to v15 so we fix this in fw-port
value of token_validity is not converted to UTC so fix it,
And groups in the field are wrong like ```account.group_system``` so set right one ```base.group_system```
Also, fix IAP buy credits message where set URL out of the Markup
Task 2179664
closesodoo/odoo#89110
X-original-commit: 1191abca6aa863cbb4a70c0329fd2271547049fa
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
before this commit:
===================
if there is multi tag on one tax line then condition is not working as expected
see below test code
```
tags
account.account.tag(33, 34)
>>> self.env['account.account.tag'].browse([33]) in tags
True
>>> self.env['account.account.tag'].browse([33, 34]) in tags
False
```
after this commit:
==================
if there is multi tag on one tax line then condition working as expected
see below test code
```tags
account.account.tag(33, 34)
>>> any(tag in tags for tag in self.env['account.account.tag'].browse([33]))
True
>>> any(tag in tags for tag in self.env['account.account.tag'].browse([33,34]))
True
```
introduced from here https://github.com/odoo/odoo/commit/aa43799ed9e03d473f48c34ee470330e027ae462closesodoo/odoo#88513
X-original-commit: 7cd2b25a7595cecd3b5c6a9d410f4ac31b76e8ac
Signed-off-by: Florian Gilbert <flg@odoo.com>
niyasraphy