Not entirely sure about TestAllocationRights. For TestEsEdiCommon
issue is quite obviously that it's inherited by tests which are
external, so when the `post_install_l10n` tag gets applied those tests
get run during "normal" l10n and they break.
closesodoo/odoo#98814
Related: odoo/enterprise#30825
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
plus_report_line_ids and minus_report_line_ids have now been replaced by plus_report_expression_ids and minus_report_expression_ids on tax templates.
The test was failing locally but not on runbot, because it was missing the post_install tag.
closesodoo/odoo#99462
Signed-off-by: Laurent Smet <las@odoo.com>
This commit improves the payment terms by:
- making the payment terms lines editable on-the-fly removing the need for a wizard
- refactoring the computation of the payment terms
- adds new demo data for payment terms
- adds an example section where the user can test and preview the due dates and amount of its payment terms
- adding a new parameter "Display terms on invoice". If set, the payment deadlines and respective due amounts will be detailed on invoices.
The refactoring:
- adds a field `months` (months to add after the invoice date)
- adds a field `end_month` (if True, switch to the end of the month after having added months or days)
- renames the field `day_of_the_month` to `days_after` (days to be added after the switching to the end of the month, only if `end_month` is set)
- deletes the field `option` which was too restrictive
- modifies the calculation of the payments terms taking into account these new fields
This allows some combinations that were not possible before.
Example: The French payment terms "30 jours fin de mois le 10" (which should be interpreted as "10 days after the end of the next month") can be encoded as
```
months = 1
days = 0
end_month = True
days_after = 10
```
Task id 2852814
closesodoo/odoo#91490
Related: odoo/enterprise#29661
Related: odoo/upgrade#3524
Signed-off-by: Laurent Smet <las@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>
On a bank statement line:
If a foreign currency is set and the amount in currency is not set, the line is reconciled automatically (because the amount is 0) and this should not be the case.
Add a constraint on `account.bank.statement.line`: raise an error if the foreign currency is added, but the amount in currency is not.
This conflicts with the tests that allow this behaviour, so the related tests are deleted as this should not be allowed anymore.
task-2956422
closesodoo/odoo#99028
X-original-commit: 1dfa3d074c7368abb51df56cb7fd1ee5115399b1
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Current task is not covered the whole cash discount feature. For now, we decided to revert the current feature and make a new more complete one later.
This reverts commit 7482aff6d7.
closesodoo/odoo#98986
Related: odoo/enterprise#30783
Signed-off-by: Quentin De Paoli <qdp@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
When using CABA and reversing a move, we expect the CABA move to
be the one impacting the tax grids, and not the reversed move.
Thus, we now avoid setting the tax grids for CABA taxes on
move lines created when making a reverse move.
Task id # 2895267
closesodoo/odoo#98789
X-original-commit: 5dd50ac1433be262ddd49d8b165e240afd16e675
Signed-off-by: Laurent Smet <las@odoo.com>
The aim of this commit is to improve UX by helping the user to find duplicate
bills in a more convenient way.
With this commit, when a user create a bill or credit note on bill that might
be a duplicate, a warning banner is displayed on the Form view of the
account.move.
On this banner there is a button that leads to the list of the duplicate
bill/credit note.
The previous warning message on post is also replaced by a RedirectWarning
Context:
Previously, the warning for duplicated bills was thrown when the bill was
saved. This was changed with https://github.com/odoo/odoo/pull/81748
It made the blocking warning being delayed until the bill is posted.
Previous to this commit:
A duplicate bill can only be detected automatically when posting the bill with
a non convenient blocking warning preventing the user to post his bill(s).
After this commit:
- A warning banner is displayed on the bill form during the bill creation.
- The banner contains a button leading to the list of duplicates.
- The blocking warning is improved by providing redirections to the duplicate
move.
closesodoo/odoo#81765
Community-pr: https://github.com/odoo/odoo/pull/81765
Task: #2612299
Signed-off-by: William André (wan) <wan@odoo.com>
Currently, computing an account's current balance takes canceled and
draft invoices into account. Only posted invoices should be considered.
opw-2896728
closesodoo/odoo#98843
X-original-commit: d3a7115feab9ca1bd8372f4450d3abc3eb52cdb0
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Fix the accounting date in a few scenarios, such as exchange difference
or CABA moves reversal.
Also avoid updating the currency rate when reversing exchange difference
moves.
closesodoo/odoo#98543
X-original-commit: 2b8df0c111a785a9e51dc2f528ac5b00cb0eadb9
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
Improvement of https://github.com/odoo/odoo/commit/e66663b52920ad5a647b03a8fd9ade4070f09158
The commit mentioned above introduced a bug, which
prevent the user to select payment method when register
a payment for multiple partners, even if the payments
were from the same type.
The solution here is to allow the selection of payment method
in any case, the _create_payment_vals_from_batch method will
change the payment method if it is not available on the journal.
Note: for the forward port from 15.0, only test is adapted, as the bug
does not happen.
opw-2954325
closesodoo/odoo#98574
X-original-commit: d16946b450356922b69e6152bd343229ed4d2bb3
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Purpose :
Improve multiple use cases while handling the Accounting part of Cash Discounts in Odoo.
When creating a Payment Term, the user can now specifically design an early payment discount through an additional part in the wizard.
This will, amongst other things, allow the user to choose in which way the tax should be computed on the discounted invoice (tax included/excluded).
The discounted amount and the conditions to fulfill are printed below the invoice PDF, as well as the details.
Registering a payment while filling the condition for an early payment discount will prefill the fields accordingly.
Reconciliation --> In the reconciliation widget, the logic of Early Payments Discounts are also applied.
Related : odoo/enterprise#28607
Task:2729038
Part-of: odoo/odoo#94050
This commit fix a bug noticed when fixing this other
one in v15 https://github.com/odoo/odoo/pull/93943.
We notice that, in addition to not set correctly
the payment type, the payment method was wrong too.
With this commit, when creating payments from batch,
we check for each payment if its type is the same
as the one set on the wizard. If not (which means
that there are payments of differents types), we set
the payment method regarding the payment type.
opw-2852186
closesodoo/odoo#98153
X-original-commit: af1fab8dab141c49d98b431a40a5ce98f2f3249c
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
When register a payment for a bill an a credit note,
the two payments have the same type.
Steps:
- Create a Vendor Bill, and a Vendor Bill Credit Note
- Select both and register payment without grouping them
-> The two created payments have the same type
With this commit, if the field group_payment is True, we
set the payment type regarding the balance of the move line.
opw-2852186
closesodoo/odoo#98010
X-original-commit: 2ad78818b59350cf5e9367802c41820e36d05db1
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@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>
We keep the statement line note when changing
the partner in reconciliation widget
Steps:
- Create a Bank Statement, a Bank Statement
Line BSL with a note (field narration)
- Save, edit, change partner on statement
line and save.
-> The note on BSL is empty
With this commit we allow narration computation
only for sale documents.
opw-2832287
closesodoo/odoo#97125
X-original-commit: 19394d1971259933c5158139c56344c9c35bdaed
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
As we allow editing balances in processing state, we do not want
to check balances before the validation of the bank statement
(only in case of a bank journal).
Commit about editing balances: 03f83eb87da00938b9d2df78651c1e06cf8a6d58
This fix split the _check_balance_end_real_same_as_computed into
2 functions. One to check "bank" bank statement and one to check
"cash" bank statement. It allows to keep the same behavior for
a "cash" bank statement when we post the bank statement, and
having the right behavior for a "bank" bank statement.
opw-2835728
closesodoo/odoo#97153
X-original-commit: 2d97efb4c84f647be3eb03f249c52b236bf00d55
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Task 2888204
- Name is automatically split into code and name
- account_type is computed based on the closest parent of the code prefix (and can be changed)
- _onchange_name is needed to split name into code and name when creating from a related model's form
closesodoo/odoo#94171
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
For a non well identified reason, the user doesn't have the uom group
to see the field during the test.
this commit adds the group to the user to make it visible during
the test as a simple fix.
closesodoo/odoo#95741
Signed-off-by: Denis Ledoux (dle) <dle@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>
In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.
This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.
This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.
As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.
closesodoo/odoo#94337
Related: odoo/enterprise#28936
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
By trying to avoid concurrency issues while assigning the sequence [1],
we are locking too many operations even when not in the process of
assigning a new number.
* when computing `highest_name`, we don't need to lock as this is mostly
an information on the form that can possibly change anyway while the
form view is open (without any lock anymore)
* when computing the accounting date, we don't need to lock, the only
information we want is the format of the sequence (yearly, monthly, no
reset), which is not likely to change on a same journal.
* when changing the `journal_id`, it is only a helper for encoding, if
there is a concurrency error it will be shown during the post anyways.
Also same argument as for `highest_name`
[1] https://github.com/odoo/odoo/commit/ba6ee0b75d66d6f22a592b1b6a7c5158461bec41closesodoo/odoo#95480
X-original-commit: 809557cdd02fe6581ed573b58158a927aabe0694
Related: odoo/enterprise#29212
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Step to reproduce:
- Create a SO, save and confirm it
- Create an invoice, on edit mode, change the journal and click on save
Issue:
- If the invoice is the first one in the current month, a sequence
number is automatically assigned and an error is displaid.
forwardport of https://github.com/odoo/odoo/commit/b8328e45d526d276b5781da3523a0d5874da64bd
opw-2660571
opw-2879716
closesodoo/odoo#79084closesodoo/odoo#95386
X-original-commit: 7b296982139518460405fa63eca6774bd82ba7b1
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Minet Adrien (admi) <admi@odoo.com>
In module mail, invalidating 'message_ids' on a mail thread also
invalidates its inverse field 'res_id' on messages. If you haven't
flushed it before, your cache will be inconsistent, as shown by the test
/mail:TestMailgateway.test_message_process_bounce_records_channel.
In module purchase_stock, add depends on report.stock.quantity. This
ensures that when the model is queried after changes in other models,
the data on which the SQL view depends is flushed to the database before
querying that model's table.
closesodoo/odoo#66938
Related: odoo/enterprise#16722
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
It seems most accounting tests relied on the fact that the "accountman"
test user has both the user AND manager groups (but previously, the
manager group was given by the implied group relation "Settings" ->
"account manager")
Part-of: odoo/odoo#91909
This commit:
- adds a fiduciary mode which allows fast encoding of invoices. This is an Accounting setting which must be activated. This fiduciary mode allows one to edit directly the invoice sequence and enter the total amount of the invoice (by creating a single line which contains the base price, the tax amount, and the most frequent account) such that we match this 'quick total amount'.
- adds a new test for this feature
- adds a 'quick edit total amount' in the tax computation which verifies that the 'quick edit total amount' correctly matches sum of the base and the tax (in case of fiduciary mode)
- sorts and filters the accounts suggestions in an invoice line. The most frequent accounts for a particular partner rank higher while filtering on the type of account suggested (this is disabled if the user searches itself for the account)
- selects by default the most frequent account for a particular partner when creating a new invoice line
- adds the option to hide some columns (label & quantity)
- moves the car column after the account column in case the Fleet app is installed
Task-id: 2857253
Community PR: odoo#91938
Enterprise PR: odoo/enterprise#27605
Part-of: odoo/odoo#91938
Task 2843455
When an exchange difference is linked to a payment, not an invoice,
it is not displayed in the payment widget even though an exchange
difference move is created and matched with the invoice.
Exchange difference should be displayed when it's linked to the payment as well.
closesodoo/odoo#92069
Signed-off-by: Laurent Smet <las@odoo.com>
Have Tax A and Tax B both configured with tax exigibility based on
payment
Have a Tax G set as group of taxes with A and B as childs
Make an invoice with Tax G on a line
Register a payment
The CABA entry will be generated without base line
This occur because the system checks for the base line tax exigility,
but the exibigility of a group of taxes is fixed to 'on_invoice' so we
need to check the value on the childs
opw-2858656
closesodoo/odoo#93131
X-original-commit: 766802c345aaae0d9d01ec17685e9742f27526e0
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Recurring entries are created using the 'auto_post' selection field
- 'no' for regular entries
- 'at_date' for non-recurring auto-posted entries
- 'monthly', 'quarterly', 'yearly' for recurring auto-posted entries
Auto-posted entries can also be posted manually.
For recurring entries, the next one is created upon posting.
See : odoo/enterprise#27798
See : odoo/upgrade#3543closesodoo/odoo#92348
Task: 2855545
Signed-off-by: William André (wan) <wan@odoo.com>
- Refactor the bank reconciliation widget to use more standards views and have a side-by-side kanban/widget views instead.
- Make sure the bank reconciliation widget is doing the same thing as the "reconcile" method on account.bank.statement.line. Then, what you see on the view is exactly what you get on the corresponding journal entry.
- Since the "reconcile" method is gone, clean the matching rules since it's now called only for one statement line at a time. Also, move the auto_validate feature into a CRON to avoid performance issues when opening the widget.
closesodoo/odoo#91448
Task: 2555114
Related: odoo/enterprise#27360
Related: odoo/upgrade#3555
Signed-off-by: William André (wan) <wan@odoo.com>
Currently, the currency conversion rate used is based on the accounting date on invoices and bills.
According to partner feedback and the official documentation we should use the exchange rate on the invoice/bill date.
Moves that are not invoices or bills should still use the accounting date.
closesodoo/odoo#87984
Task: 2807136
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Journal entries of a bank statement can be reset to draft even if the
bank statement has been validated
Steps to reproduce:
1. Install Accounting
2. Go to Accounting dashboard, click on the 3 dots of Bank and go to
View > Statements
3. Create a new statement with a transaction of 100, correctly set the
ending balance, save and post
4. Click on reconcile then validate the reconciliation
5. Go back to the statement and validate it
6. Open the journal entry of the statement
7. You can reset it to draft but you shouldn't be able to
Solution:
Prevent the user from resetting a journal entry to draft if the
statement has been confirmed
opw-2827117
closesodoo/odoo#92713
X-original-commit: 5622bc103e063d62f75625ca413a06aa7395d654
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Rationnals
----------
Web servers can serve some resources (e.g. static files) right away
without any interaction with the web application. The network model of
most web servers makes them capable of handling thousands of
simultaneous requests when it comes to intensive IO operations such as
streaming data from a file. The network model of Odoo is different: it
is capable of a lot of processing power but can only serve a handful of
requests at a time, i.e. Odoo (with some help from postgres) is
optimized for CPU operations, not IO.
Some users don't configure their web server, they use a basic
configuration that relay all requests to Odoo. The result is that many
Odoo HTTP Workers can be busy streaming static files instead of
processing other requests. This can lead to a worker starvation, i.e.
all workers are busy streaming files and cannot process new requests.
X-Sendfile
----------
In this work, we add the support for the [X-Sendfile] header family,
they are multiples http headers that can be used by the web application
to communicate with the web server in order to delegate the delivery of
files stored on the file system. Odoo still receives the request but it
does no more stream the file content from within its HTTP worker,
instead it skips the response body altogether and sets the `X-Sendfile`
special header with the path of the file on the filesystem. The web
server intercepts that special header, open the file and stream it.
Using those headers, we can use the best of both the web application and
the web server. The web application is still responsible to locate the
resource and verify the access rights, the web server is still
responsible of streaming the content.
Using X-Sendfile is opt-in via the `--x-sendfile` CLI flag. We set both
`X-Sendfile` (apache) and `X-Accel-Redirect` (nginx). If you are using
apache, make sure `mod_xsendfile` is enabled. If you are using NGINX
you have to add the following location block:
location /web/filestore { # custom path, hardcoded within Odoo
# Prevent access from the outside world, i.e. makes this
# route only accessible via X-Accel. MANDATORY!!!
internal;
# Give access to the filestore using this server's
# permissions. Odoo is in charge of verifying the access
# rights.
alias /path/to/odoo/data-dir/filestore;
}
The Odoo [deployment documentation] has been updated accordingly.
[X-Sendfile]: https://www.nginx.com/resources/wiki/start/topics/examples/xsendfile/
[deployment documentation]: https://www.odoo.com/documentation/master/administration/install/deploy.html#serving-static-files-and-attachments
Changes to the API
------------------
To benefit most from X-Sendfile, all APIs related to streaming content
over HTTP has to be adapted. They are: (1) `request._serve_static`,
(2) `ir.http._serve_fallback`, (3) `/web/content` and (4) `/web/image`.
Each used it own way to deliver content: (1) `_serve_static` was using
`send_file` (flask's send_file that as been vendored with odoo 10
years ago and not maintenained since then), (2) _serve_fallback was
handcrafting a `werkzeug.wrappers.Response`, (3) /web/content-image were
using the "binary server" `ir.http.binary_content` API.
I has been decided to remove all 3 APIs and to merge the code inside of
the new `http.Stream` object and the `ir.binary` helper model.
A Stream wraps what is going to be sent to the browser, it can be a path
to a file on the locale filesystem, a blob of raw data or an URL to an
external resource. The Stream also holds various metadata that are
mainly used for caching. The preferred way to create a Stream is via one
of its three factories so that all the metadata are set. The factories
are: `from_path`, `from_attachment` and `from_binary_field`. A stream
instance exposes a single method `get_response()` used to create the
corresponding HTTP response object out of the stream.
Inside of `ir.http` were a few methods that were not related to the http
routing and formed what was called the "binary server". All those
methods have been removed and the feature have been refactored inside of
the new `ir.binary` model. The removed methods are:
- `_xmlid_to_obj`
- `_get_record_and_check`
- `_binary_ir_attachment_redirect_content`
- `_binary_record_content`
- `_binary_set_headers`
- `binary_content`
- `_response_by_status`
- `_get_content_common`
- `_content_image`
- `_content_image_get_response`
- `_placeholder_image_get_response`
The new `ir.binary` abstract model exposes the following utilities:
**`_find_record`**
Find an attachment or a record with a binary-field out of an xmlid or
out of a pair record-model/record-id. Check the access rights and the
access token.
**`_get_stream_from`**
Create a Stream from an attachment or a record with a binary-field.
**`_get_image_stream_from`**
Same as `_get_stream_from` but adapted for images. It sets a sensible
ETag on the stream and has image resizing support.
**`_placeholder`**
Get the image placeholder blob.
Testing
-------
It is possible to test the web server configuration using the
`test_http` module. Install the module then run the unittest using the
`webserver` test-tag. By default it attempts to connect to a web-server
running on `http://localhost:80`, you can change this URL by setting the
`WEB_SERVER_URL` environment variable.
odoo-bin -i test_http --stop-after-init
WEB_SERVER_URL='http://localhost:80' odoo-bin --test-tags webserver --stop-after-init
closesodoo/odoo#88134
Task: 2801675
Related: odoo/documentation#2083
Related: odoo/enterprise#26191
Signed-off-by: Julien Castiaux <juc@odoo.com>
This fix will try to write a new amount value on the tax when an
invoice is created from POS, that will raise a user error preventing the
creation of the order.
This reverts commit 2b9592cb0ecef235d708ed7810d0613ccd946124
OPW-2855694
closesodoo/odoo#91719
X-original-commit: d3cce0e3ae13859954d6907a3cb16fb0e1a95f86
Signed-off-by: Masereel Pierre <pim@odoo.com>
- Create an invoice of 1200 MXN = 300 USD
- Register a payment, select USD at a date at which 1200 MXN = 400 USD
=> The amount is incorrect, a difference is computed but it should be zero.
closesodoo/odoo#91634
X-original-commit: d88f630dcb7f98a45c9efe7f2439a8732832c77c
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
This is actually checking if for each tax of each line of invoice in the move, there exist a tax entry.
This will prevent the users from accidentally or dully erasing tax lines which includes 0% taxes.
If the users delete the line containing tax, it will be added again the same way as the counterpart line
for an invoice line is being added.
Also, fixes the following:
Recalculating all invoices if a single invoice in a batch has a line with `recompute_tax_line` set should not be allowed.
Deleting a tax account entry of a posted move should not be allowed.
task ID:2834679
closes odoo/odoo#91414
Pr: #90834
X-original-commit: 5f39f8c1533502be52ea9d3ef114430b5b8cd9a6
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- Create invoice for a prudict at price X > 0
- Change the price to 0 before saving
- Then save it
-> Error : Cannot create unbalanced journal entry
This bug was introduced in 14.0 with this commit fe7d56dc32c71e04b54de9dbd756a48942a832f4
With this commit, we use an ugly condition to catch the
specific case of a tax with price included and amount type division
to avoid changing the price unit if the line balance is zero.
opw-2822635
closesodoo/odoo#91059
X-original-commit: 2b9592cb0ecef235d708ed7810d0613ccd946124
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>
Currently, when the user removes a tax from an invoice line (tax_ids), the tax grid stays on the account move lines,
after this commit, when the tax is deleted in invoice line, the related tax_tags are removed from `aml.tax_tag_ids` which is the correct behavior
task ID:2843666
closes odoo/odoo#90950
Pr: #90836
X-original-commit: 27b3d3412b347ef7fb62626d5087eaf34621395a
Signed-off-by: Laurent Smet <las@odoo.com>
Loading the demo data of Accounting app when only Japanese language is
installed will raise an error because there is a non-unique alias_name
Steps to reproduce:
1. - Run odoo with parameters `-d [db_name] --without-demo all
--load-language ja_JP -i l10n_jp,account_accountant` (you can also
install those apps using the UI but only Japanese should be installed
so it will be in Japanese)
- Or create a trial database on odoo.com with Accounting installed,
using Japan as country and Japanese as language
2. Activate debug mode and go to Settings, scroll to the bottom and load
the demo data (`デモデータをロード`, last link in 'Developer Tools')
3. A validation error is thrown
Solution:
When building the alias name, if the name of the journal is not in
ascii, use the journal's code or type followed by the company's name. If
the company's name is not ascii, use the company id as suffix
Problem:
When a journal with non-ascii characters in its name is created, its
alias name fallbacks to the journal's code. In the demo data, two
journals have the same code. It will try to create the second journal
with the same alias name, violating the unicity check in
`_clean_and_check_unique`.
opw-2831638
closesodoo/odoo#90969
X-original-commit: 91d26b32250a74684dacad8350ac4452fa082384
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
With this commit, we make sure that all lines are fully reconciled when
reversing a move.
Steps to reproduce:
- Create a Journal Entry, with eg a line with 300$ debit/credit and two others
lines to make the journal entry fully balanced
- Then reverse the move
-> Only one line is marked as fully reconciled, the other one is marked
as partially reconciled.
This is because each line was passed in the reconcile method with
all the counterpart lines, even those which didn't belong to it.
Therefore, all the firsts lines was marked as partially reconciled
until the last one, which passed with the only counterpart line
left.
With this commit, we group the lines and counterpart lines by account,
and reconcile them.
opw-2810392
closesodoo/odoo#90928
X-original-commit: 0a03d029f93f6c0f31f6617c00943aa2dfcd937b
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>
Description of the bug :
Registering a payment for two confirmed bills/invoices from different partners would result in a stack trace.
Steps to reproduce :
Create a bill from a specific partner and confirm it.
Create another from another partner, confirm it.
From the list view, select both those documents, click Register Payment.
The StackTrace appears.
FIX :
handled the case by setting the payment_difference field to 0.0 if the wizard contains multiple payment batches.
Modified some tests to detect this behaviour in the future.
closesodoo/odoo#89757
X-original-commit: def467e82b12c5ec7284ed9c966bb13ab3a77298
Signed-off-by: Laurent Smet <las@odoo.com>
Add a check in 'AccountTestInvoicingCommon' to ensure that all
tests using it are run in post_install.
These tests cannot be run at install, thus they would be ignored
and wouldn't run on the Runbot.
X-original-commit: 659ee179e1beed962026e3abac1bda322c2ac964
[FIX] account,*: Ensure tests using TestInvoicingCommon runs
Add a check in 'AccountTestInvoicingCommon' to ensure that all
tests using it are run in post_install.
These tests cannot be run at install, thus they would be ignored
and wouldn't run on the Runbot.
closesodoo/odoo#90242
X-original-commit: ec36b403edda3fbe3b5bd5f30f31ef6bad680967
Related: odoo/enterprise#26791
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Xavier Morel