This commit makes hotkey uses more coherent throughout the entire
codebase by setting alt+q as main shortcurt for confirm and default
actions and alt+x for cancel actions.
task-3370463
closesodoo/odoo#127469
Related: odoo/enterprise#43694
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Prior to this commit, the SVG's viewBox attribute was missing, which
prevented svgs from being scaled.
This commit fixes this issue.
task-3326633
Part of task-3326263
X-original-commit: 30300c373ad1c63a6cf8b035cae0785a09c6933f
Part-of: odoo/odoo#121886
As the number of `account.move`, `account.move.line`,
`account.bank.statement.line` and `account.journal` is growing, the
accounting dashboard, which is the entry point of the app, gets slower
and slower.
There are multiple issues being addressed in this commit:
* The data for each journal is computed journal by journal. This means
that the number of queries run increases linearly with the number of
journals. While the boilerplate around running multiple queries is
negligible compared to the running time of the queries in this case,
some queries take as much time to run for one journal or for many.
To improve this, all the queries are now batched. This has been done
by refactoring the code; all these functions are now called on as many
records as needed[^1]:
- `_get_journal_bank_account_balance`
- `_get_journal_outstanding_payments_account_balance`
- `_get_last_bank_statement`
- `get_line_graph_datas`
- `get_bar_graph_datas`
- `get_journal_dashboard_datas`
* The gap detection and the entries' count are computed fields
(`has_sequence_holes` and `entries_count` respectively). We don't need
to display/compute these fields for all types of journals, but since
they were mentioned by using a `<field/>` node in the view, they were
computed for all journals displayed. Instead of using the `<field/>`
node, we are now setting the value in the `kanban_dashboard` field.
* Documents in foreign currencies on journals in foreign currencies need
to get the rate in order to be aggregated in the journal's currency.
There are 3 cases:
- Document in journal's currency
- Company's currency is the same as the journal's
- Document, company and journal have 3 different currencies
Before this commit, the second case will still fetch the daily rate
for the document in order to do the conversion, but we actually
already know the conversion; it is stored on the document.
Benchmark
=========
On a `populate` database with:
- 4 `res.company` (with accounting enabled)
- 45 `account.journal`
- 19k `account.move`
- 140k `account.move.line`
- 4k `account.bank.statement.line`
- 4 `account.bank.statement`
| Query count | Query time | Remaining time
--------------------------- | ----------- | ---------- | --------------
Before fix | 279 | 0.333s | 0.375s
After fix (without update) | 40 | 0.120s | 0.170s
After fix (with update[^2]) | 38 | 0.100s | 0.170s
Note that the currency conversion was disabled because the populate
database doesn't represent a realistic dataset regarding this. Disabling
it only improves the numbers before the fix.
Note
====
A lot of the time remaining comes from the aggregation of
draft/unpaid invoices with the correct rate done in python instead of in
SQL. This commit doesn't change the behavior but this could be rethought
from a function point of view.
________________________________________________________________________
[^1]: the old functions have been kept for compatibility, new ones are
suffixed by `_batched` and made private if it wasn't the case.
[^2]: some optimization require the views and indexes to be updated
closesodoo/odoo#117964
X-original-commit: 0a386932d2cbcb44cf36c1830422e52b285ae990
Related: odoo/enterprise#39461
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this PR, the res config for the accounting page needed some UI fixes (checkbox misplaced, missing attrs invisible). This PR fixes that.
closesodoo/odoo#115212
Task-id: 3226604
X-original-commit: 33107e37cc007924fbe04d04cc2e9bdc0d3a60c4
Related: odoo/enterprise#38156
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
Steps to reproduce:
- Create a new journal Bank
- In Sequence, find the 'New Bank Check" and edit it so the sequence can be 10 number digits long
- Create a Vendor Payments with the the New Banck and Check as a method
- Click on Print a check
- Set the check number to 2147483648 and validate
- Create a new payment with the check method
- Click on Print a check
Issue:
Error is raised
Cause:
As for https://github.com/odoo/odoo/pull/112832 there is a second check in order to increment the check number
opw-3140973
closesodoo/odoo#114496
X-original-commit: 531147bb5fad6372c3742bc061f78687f7f11e5b
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- Create a new journal Bank
- In Sequence, find the 'New Bank Check" and edit it so the sequence can be 10 number digits long
- Create a Vendor Payments with the the New Banck and Check as a method
- Click on Print a check
- Set any number > 2147483647 and validate
Issue:
Traceback
Cause:
The query SQL make a check to verifiy that the number is correct ('025'::integer == '25'::integer but '025'!='25)
But using INTEGER limits the number up to 2147483647 (https://www.postgresql.org/docs/current/datatype-numeric.html)
Solution:
Use BIGINT whose limit is 9223372036854775807
opw-3140973
closesodoo/odoo#113499
X-original-commit: 49dd9dffd7b96fd90860123f8b3f0e623979b246
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Be able to add multipe checks payment method on journal
accountamatata task 3130305
closesodoo/odoo#109774
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
This is mostly a cleaning/refactoring change.
The current API for init hooks (pre, post, uninstall) is to pass
`cr, registry`.
But the first thing which was done by most
post init and uninstall hooks was to create an env using
the cr passed
e.g.
`env = api.Environment(cr, SUPERUSER_ID, {})`
and the `registry` argument was unused in all these hooks,
completely.
By changing the API of hooks to pass `env` instead
of `cr, registry`, we gain in average two lines in every
hooks:
- the line creating the env `env = api.Environment(cr, SUPERUSER_ID, {})`
- the line importing `api` and `SUPERUSER_ID`
Therefore removing ~250 lines of repeated code lines accross odoo/odoo and
odoo/enterprise.
In addition to these lines removed,
it also ease the API of init hooks for Odoo developers,
who are used to that `env` and not so much how to create an `env`
from a cursor.
Part-of: odoo/odoo#108254
In order to make this modules to also match new module l10n_latam_check.
* refactory of some methods to make it more heritable
* check number now is showed only when is defined and is related to
check_printing payment method.
X-original-commit: 9394903813947cd4bfbad87f077cdf67233907d8
Part-of: odoo/odoo#107163
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>
When printing a check that comes from an expense,
the check has no reference to the move from which
the payment has been created.
The reason is that we filter the move by taking
only outbounds to complete the check informations,
but moves from an expense are of type entry.
With this commit, we allow moves coming from
expense to be taken into account by adding a
check on move.move_type.
opw-3044141
closesodoo/odoo#105157
X-original-commit: b588329a45633f0dec89fe195cf24a8b3671dedd
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@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>
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>
Task: 2856281
- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed
closesodoo/odoo#93212
Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Since 'check_number' is now part of the journal item's label, the account_accountant_check_printing module is no longer necessary.
Task: 2555114
Part-of: odoo/odoo#91448
With this commit, we allow mutliple payments with manual
check printing.
Steps to reproduce:
- With manual check numbering
- Create +=3 vendor bills
- In bills list view, select all bills and register payment
- Select Checks as payment methos, and validate
-> Validation Error: The following numbers are already used ...
Setting the check_numbers before calling the super of
payment.action_post.
opw-2830586
closesodoo/odoo#91128
X-original-commit: c26cd9fa30ac9093f5c7500ca1dd9a9f9cfd06a5
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>
In some languages and layout the currency symbol might be wrapped in a separate
line, which is not acceptable from accounting point of view. Fix it by replacing
space with a special symbol.
STEPS for v15:
* install MX localization;
* create a Spanish speaking customer
* generate a pdf:
1) Create quotation with products
2) Add IVA 16%tax
3) print a report
BEFORE: the currency symbol is incorrectly displayed on a separate line
AFTER: currency symbol is always with the amount
---
https://github.com/odoo/odoo/pull/89722
opw-2829138
closesodoo/odoo#90961
X-original-commit: 684687226b87022bc9f9ba7667b295e545100645
Related: odoo/enterprise#27138
Signed-off-by: William André (wan) <wan@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>
Fix two issues linked to payment methods and their journal link.
SEPA Credit Transfer was marked as only available on EUR journals, but
from what we have been told, and we have seen, it should also be made
available for other currencies (CHF/SEK).
So we are changing the rule used to determine if SEPA Credit Transfer
is available on a journal to allow to use it on journals using CHF or
SEK as a currency.
There is another issue, where the filtering is done differently at the
journal creation and when the user add the payment method manually in
the lists.
The filter rules were not respected at the journal creation, which
would lead to incorrect default inbound and outbound payment method list.
For example, a new journal would have the company currency (let's say,
USD) but still have SEPA Credit Transfer (EUR,CHF,SEK) added on it by
default while it should not be available there.
opw-2777522
X-original-commit: 0ad8faf3bfc7b28e5668c3445fcc06c24ad98354
[FIX] account_*: payment method journal filter
Fix two issues linked to payment methods and their journal link.
SEPA Credit Transfer was marked as only available on EUR journals, but
from what we have been told, and we have seen, it should also be made
available for other currencies (CHF/SEK).
So we are changing the rule used to determine if SEPA Credit Transfer
is available on a journal to allow to use it on journals using CHF or
SEK as a currency.
There is another issue, where the filtering is done differently at the
journal creation and when the user add the payment method manually in
the lists.
The filter rules were not respected at the journal creation, which
would lead to incorrect default inbound and outbound payment method list.
For example, a new journal would have the company currency (let's say,
USD) but still have SEPA Credit Transfer (EUR,CHF,SEK) added on it by
default while it should not be available there.
opw-2777522
closesodoo/odoo#88677
X-original-commit: e2cd91ad8339f73b2547bc839e675443528f3adf
Related: odoo/enterprise#26172
Signed-off-by: Florian Gilbert <flg@odoo.com>
Unnecessary call to _create_check_sequence because is called in create method and create is called in supper().copy()
TT35608
closesodoo/odoo#88159
X-original-commit: 2f83737b8eb4f2b378cf4d6a6348d9ba15200561
Signed-off-by: Florian Gilbert <flg@odoo.com>
* Previously, when reconciling journal items in multi-currencies, the exchange difference entry was created only on the full reconciliation. It will now be created directly at each partial to ensure the ratio between amount_residual_currency and amount_residual is always kept identical.
* Also when reconciling two lines, one with a foreign currency and one expressed in company currency, the reconciliation is now made based on the foreign currency.
==== RATIONALE ====
This patch allows to fix the following use cases (among others)
1) When everything is expressed in foreign currency, the reconciliation is made in that currency:
Suppose EUR is the foreign currency and USD is the company currency. Reconciling:
L1: 120 EUR 60 USD (rate 2:1)
L2: 240 EUR 80 USD (rate 3:1)
..leads to a partial of 120 EUR and min(80, 60) = 60 USD
After the reconciliation, L1 is fully matched but L2 is still open with 120 EUR but only 20 USD.
This is the first problem is the current reconciliation because L2 is supposed to have a rate 3:1 so the residual amount should be 120 / 3 = 40 USD.
Since the rate is no longer consistent on L2, the user will probably close the reconciliation by using another line in EUR or will close manually the reconciliation with 20 USD but without any additional exchange difference journal items explaining where this unconsistency comes from.
2) When the current lines are mixing multiple currencies, the reconciliation is made using the company's currency.
In some countries like Mexico, Ethiopia or Costa Rica, the customer is free to pay an invoice using the company's currency instead of the foreign one.
So, suppose USD is the foreign currency and MXN is the company currency.
The invoice is expressed by:
L1: 120 USD 60 MXN (rate 2:1)
If the customer is paying at a date in which the rate is 3:1, he is free to pay
either L2: 120 USD 40 MXN (rate 3:1), either L2: 40 MXN.
In the second case, he is expecting the invoice to be fully paid because its paiement is equivalent to 120 USD at the payment date.
In Odoo, the second case led to an open balance of 20 MXN and the invoice was not completely paid.
Even this situation could be easily fixed by a manual write-off, this makes the Mexican payment EDI very complicated to fullfil correctly because the government is expecting a complete matching between the invoice and the payment.
When the customer is paying multiple invoices or the invoices are paid using multiple payments, the currently generated mexican EDI file in Odoo was wrong.
==== REFERENCES ====
Original idea suggested by hbto@vauxoo.com. Thanks for the contribution and patience of the many persons having, at some point, helped on that.
github issue: https://github.com/odoo/odoo/issues/37469closesodoo/odoo#84201
Task: 2669371
Related: odoo/enterprise#24268
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Steps to reproduce:
- On bank journal, set at least two manual
outbound_payment_method_line_ids
- Set a vendor X with manual property_payment_method_id
- Create a Vendor Bill with vendor X, confirm it, and register payment
OR
- Create a payment with outbound method and select vendor X
Issue:
Got a traceback
The reason is we expected one value instead of several.
With this commit, we take the manual payment method with the
highest priority based on its sequence number.
opw-2743110
closesodoo/odoo#86270
X-original-commit: 6235466e70cefd5d948ce06dd39fb04d88387a43
Signed-off-by: William André (wan) <wan@odoo.com>
When install the module on a db with huge amount of account move,
prefetching data when accessing partner_id of first move iteration is
costly and should be avoided.
closesodoo/odoo#84989
X-original-commit: c80700ee616e5588669879fd5e020ea868665a8f
Signed-off-by: William André (wan) <wan@odoo.com>
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
The method constraint to validate the Check Number is slow
1. Analyzing the following query:
```sql
SELECT
payment.check_number,
move.journal_id
FROM
account_payment payment
JOIN account_move move ON move.id = payment.move_id
JOIN account_journal journal ON journal.id = move.journal_id,
account_payment other_payment
JOIN account_move other_move ON other_move.id = other_payment.move_id
WHERE
payment.check_number::integer = other_payment.check_number::integer
AND move.journal_id = other_move.journal_id
AND payment.id != other_payment.id
AND payment.id IN (1085159)
AND move.state = 'posted'
AND other_move.state = 'posted';
```
The output is:
Planning Time: 3.354 ms
Execution Time: 2514.660 ms
Discarding null values
```diff
AND other_move.state = 'posted';
+ AND payment.check_number IS NOT NULL
+ AND other_payment.check_number IS NOT NULL
```
The output is
Planning Time: 3.216 ms
Execution Time: 0.140 ms
2. The constraint is computed even if the payment is not a check (check_number is empty)
Returning early save useless extra computating
It is not needed to compare falsy values for duplicated for whole table
3. The validation to check is it not a number is not optimal
It is transforming the string -> integer -> string to check if the string is not a number
but it is enough using only string -> integer not needed to transform to string again
python3 -m timeit -u msec -s "check_numbers = [str(i) for i in range(1000000)]" "[str(int(i)) for i in check_numbers]"
> 1 loop, best of 5: 323 msec per loop
python3 -m timeit -u msec -s "check_numbers = [str(i) for i in range(1000000)]" "[int(i) for i in check_numbers]"
> 2 loops, best of 5: 135 msec per loop
It is better but not enough, using `str.isdigit` method is 5x faster than original approach
python3 -m timeit -u msec -s "check_numbers = [str(i) for i in range(1000000)]" "[i.isdecimal() for i in check_numbers]"
> 5 loops, best of 5: 64 msec per loop
closesodoo/odoo#83851
X-original-commit: 31e0ed8c957e8a6af7f6bd5d449b450967206eab
Signed-off-by: Olivier Colson <oco@odoo.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Define `data-hotkey` on most used action buttons.
For the modals, the following keys are dedicated for "special"
actions:
- Alt+G: add
- Alt+V: save
- Alt+Z: cancel
closesodoo/odoo#73275
Taskid: 2588233
Related: odoo/enterprise#19464
Signed-off-by: Kevin Baptiste <kba@odoo.com>
To improve the payment method system, proceed to a few changes
such as changing the view a bit, making sure payment acquirers are not
linked to a journal by default and that only the manual payment method
type can be used multiple times in a single journal.
Task id #2573145closesodoo/odoo#73596
X-original-commit: 9122b367baea10e59b66e45bf7c458a6f1e82efb
Related: odoo/enterprise#19623
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The payment method added by account_check_printing is meant as:
> Preferred payment method when paying this vendor. This is used to
> filter vendor bills by preferred payment method to register payments
> in mass. Use cases: create bank files for batch wires, check runs.
But it may also select the default payment method on an account.payment.
With this changeset, we copy what is done in account.payment to
account.payment.register so the behavior is the same for it.
forward-port of #72655
opw-2508263
X-original-commit: a546e7e870987e882ab2c9a6fa2618476b76fcb8
Users may want to be able to have transactions coming from multiple
payment acquirers to be registered in the same journal.
This will allows that.
Task id #2414749closesodoo/odoo#67331
Related: odoo/upgrade#2500
Related: odoo/enterprise#17258
Signed-off-by: William André (wan) <wan@odoo.com>
Currently, across Odoo, there are around 40+ many2one fields defined with a
'selection' widget. Since the many2one widget has options to limit record
creation and opening, there is no reason to define a many2one field with a
selection widget. The selection widget does not allow for searching, and is
limited to 100 records.
PURPOSE
to update the definition of any many2one on which we applied a 'selection'
widget, and instead use the standard many2one widget with disabled
opening/creation instead.
after this commit,
for each many2one field defined with widget="selection", widget="selection" is
replaced with options="{'no_open': True, 'no_create': True}"
Task : 2476488
closesodoo/odoo#68387
Related: odoo/enterprise#17316
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce the bug:
- Let's consider a user U not in group group_system
- Log with U
- Create a vendor payment with payment method Checks
- Print it
Bug:
An access error was raised because U didn't have the rights to write on model ir.sequence
opw:2513014
closesodoo/odoo#70062
X-original-commit: 11376c88e0068a0bece0b0b56ffd4a9f296ffb87
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When printing a check from a payment the check number wizard shows the
number 1 for the next check... it should show the last check added one
+1, it doesn't because it doesn't exclude the account.payments without
checknumber.
This fix excludes the account.payments without checknumber so that it
doesn't shows "1" as the next check number when there are multiple new
checks to be printed
X-original-commit: adfb8299141cb8fe9883741c43871a51f849655e
The Payment form view is simplified for a much less cluttered screen.
A paired internal payment is now created when an internal transfer is posted.
Task: 2403336
Gorash