Steps to reproduce:
- Install purchase
- Go to Settings and activate `Variant Grid Entry`
- Create a new Requests for Quotation
- Add a customer and add a product that has a variant min 2 variant
- Wizard should ask for the variant
- Select 1 variant by increasing quantity in the grid and confirm
- Confirm order
- Add again a product variant with the wizard
Issue:
Price unit is not set on the new line.
Cause:
In `_onchange_quantity` (triggered by the purchase_product_matrix
module), we do not update price unit if order line
is in state `purchase` or `done`.
Solution:
Replace condition to not perform `_onchange_quantity` if order line
has an invoice line.
opw-2956755
closesodoo/odoo#99522
X-original-commit: 8f92146b2d4996be724213345567291f045aad85
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps to reproduce:
- Create a sale order with a product that's invoiced on delivered
quantities.
- Set delivered quantity (partial delivery) and create an invoice based
on the delivered quantity. Set the "Invoice Date" to sometime in the
past.
- Go to the settings and set "Invoicing Switch Threshold" to any date
in the future (so that the invoice you created has a date BEFORE the
new threshold)
- The invoice will get the label "invoicing app legacy".
- Go back to the sales order and change the delivered quantity.
You should see that the invoiced quantity is automatically set to 0.
A similar behavior can be observed with purchase orders.
Why this is happening:
When a new “Invoicing Switch Threshold” is set, all posted invoices
before the threshold are marked as `canceled`. In v15, changing the
delivered quantities triggers the invoiced quantities to be
recalculated as well. However, computing invoiced quantities doesn't
take into account invoices that are marked as `canceled`. This mean
that the newly computed invoiced quantities won't include invoices
posted before threshold.
opw-2896797
closesodoo/odoo#98909
X-original-commit: cc979734bd7ef3f2a94b411cb7b4f3e782b7ddab
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
By observing the slowest queries in our servers, we find some indexes
to add (and verify the pertinence of each) :
- Add a index on `sale_id` of `stock_picking` because, it has a one2many inverse highly used.
- Add a index on `product_id` of `purchase_order_line` because, it has a one2many inverse in purchase_stock and there are some search with it (in `_compute_purchased_product_qty`).
- Add a index on `product_id` of `sale_order_line` to improve the `sale.report` view and it is also called by `_compute_sales_count`.
- Add a index `btree_not_null` on `created_purchase_line_id` of `stock.move` because its one2many inverse `move_dest_ids` is highly used.
- `key` on `ir_ui_view`: Backport of https://github.com/odoo/odoo/pull/97478closesodoo/odoo#99130
X-original-commit: da55c8d88b846d9d1841712b6bd96799e2768a5b
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>
This commit converts the purchase dashboard to owl component
and removes its legacy code.
closesodoo/odoo#97590
Taskid: 2920812
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Minor UX updates in purchase and stock:
Reworded (in stock):
- Default name location "Partner Locations" => "Partners"
- Default result for "Apply All" wizard "Inventory Adjustment" =>
"Quantity Updated"
- Individual "Apply" move reference/name updated for individual quants
(i.e. "Quantity Updated / Confirmed") so that the scheduled date is
no longer included
Removed (from purchase):
- Duplicated menuitems, i.e. "Purchase > Reporting > Purchase" showed
the same thing as Enterprise menuitem and both were being displayed in
Enterprise version. Also updated the no records found help message
since old message appeared to be slightly out of date.
ENT PR: odoo/enterprise#29974
"other" part of b2b task: 2882539
Part-of: odoo/odoo#97109
The goal of this revision is to get rid of the `groups_id` field of the model `ir.ui.view`.
- This feature wasn't really known or used by most developers,
and not straight-forward to understand.
Removing it allows one less complicated thing to learn for developers.
Besides, thanks to odoo/odoo#95729,
changing the behavior of the `groups=` attribute,
we can easily get rid of this `groups_id` feature
by simply adding `groups=` in the elements of the views
using the `groups_id` field, it will have the same effect:
adding the elements in the view only for the users part of the specified group.
- By getting rid of the groups_id many2many field on ir.ui.view,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the groups_id groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
Part-of: odoo/odoo#98551
The widget `account-tax-totals-field` needs the value of the
`currency_id` field, even when not in multi-currency mode.
The widget is used in `sale.order`, `account.move` and
`purchase.order`. The only place where the field
was not included when not in multi-currency mode
was the purchase.order.
A traceback was raised when attempting
to open the purchase order form when
not in multi-currency.
This is an oversight of odoo/odoo#95729closesodoo/odoo#98597
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
*: hr_org_chart,l10n_gcc_invoice_stock_account,mail,point_of_sale,
purchase,website,website_sale,website_sale_autocomplete,
website_slides_survey
Some commit have added old Bootstrap 4 classes after the merge of
Bootstrap 5.
Note that it's not possible anymore as the merge bot is now able to
detect it.
closesodoo/odoo#98349
Related: odoo/enterprise#30551
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Add a new subtype_id for 'RFQ Sent' state. This removes
the need to join on mail.tracking.value when computing
'all_sent_rfqs'. Since mail.tracking.value is usually
a big table, removing this join leads to a substantial
speedup when loading the purchase.order dashboard on big
databases.
closesodoo/odoo#96921
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Prior to this commit, the dashboard was a table and there was
unnecessary scss.
This commit changes the table into the new bs5 grids
and clean the scss files.
In the portal view, a class(orders_label_text_align) that didn't affect
the design was removed.
task-2906527
closesodoo/odoo#95902
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Only for terms containing Credit Note and expenses
closesodoo/odoo#97840
X-original-commit: 1754b094a66476a0bdb29fe60dc5583c03336c3f
Related: odoo/enterprise#30262
Signed-off-by: Martin Trigaux (mat) <mat@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>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
The new list and form views were merged recently [1], but they
weren't activated because they weren't 100% ready yet. This is now
the case. This commit adds those views to the view registry. As a
consequence, a lot of qunit tests and tours needed to be adapted,
mostly for selector changes.
We also add legacy list and form views to the view registry, with
keys 'legacy_list' and 'legacy_form'. This allows to force those
legacy views when necessary. For instance, we did it in views
using complex custom legacy x2many field widgets that haven't been
converted yet (we have a compatibility layer but it isn't complete
and doesn't support every advanced usecases).
[1] odoo/odoo#92475
Part-of: odoo/odoo#78221
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: luvi <luvi@odoo.com>
The user executing the test is changing the UOM
while the field was invisible because the user
did not have the multi uom group.
Therefore, add the group to the user for the test
so the field is visible in the form.
This is related to revision
odoo/odoo@5ccc32fcf7
```
2022-07-12 11:59:39,526 22 ERROR master odoo.addons.purchase.tests.test_purchase: FAIL: TestPurchase.test_with_different_uom
Traceback (most recent call last):
File "/home/odoo/src/odoo/master/addons/purchase/tests/test_purchase.py", line 268, in test_with_different_uom
po_line.product_uom = uom_dozens
File "/home/odoo/src/odoo/master/odoo/tests/common.py", line 2179, in __setattr__
assert not self._get_modifier(field, 'invisible'), \
AssertionError: can't write on invisible field product_uom
```
closesodoo/odoo#95841
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>
This allows to create a purchase.order record without
the need to call the onchanges to set the suggested packaging
and quantity.
For instance, this makes easier to create purchase orders
with suggested packaging using XMLRPC.
closesodoo/odoo#95306
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
If we use the auto-complete feature to add PO's lines to an bill or we select multiple PO's then use
'create bill' button, the generated invoice line will copy the sequence line from the PO's line. This
can lead to situation where we will have all the first lines of each PO then all the second, etc, ending
with a mix of all PO's in the bill.
Example:
Purchase order 1
- seq 10 line A
- seq 11 line B
- seq 12 line C
Purchase order 2
- seq 10 line A'
- seq 11 line B'
- seq 12 line C'
Invoice created from those PO's
- seq 10 PO1:line A
- seq 10 PO2:line A'
- seq 11 PO1:line B
- seq 11 PO2:line B'
- seq 12 PO1:line C
- seq 12 PO2:line C'
After this PR this PR the lines from the same PO's will be contiguous like:
Invoice created from those PO 1 and 2
- seq 10 PO1:line A
- seq 11 PO1:line B
- seq 12 PO1:line C
- seq 13 PO2:line A'
- seq 14 PO2:line B'
- seq 15 PO2:line C'
opw-2749682
closesodoo/odoo#95343
X-original-commit: cafe5c1aff1ca1632ce4924a6b027629c283a5e9
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Beckers Thomas (tbs) <tbs@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>
Issues
------
Purchase Dashboard gives wong value for PO in RFQ and RFQ sent when
user's language is not English
Current behavior before PR:
---------------------------
1. Create some RFQ and RFQ Sent to see its statistic in dashboard
2. Swith user language to another one that is other than English
3. Statistic in the dashboard is wrong now
Solution
--------
Passing translated RFQ and RFQ Sent into the dashboard query in stead of
passing pure text without translation.
closesodoo/odoo#95248
X-original-commit: ba8ad25b413151544b85477c9aae858e99c6cfaf
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
For bugfix purposes, app administration groups have been given to
(implied by) the "Settings" group because without those rights,
opening/saving the settings crashed.
1) Do not load hidden view content
This commit uses the conditional inheritance of views
(depending on user groups) to avoid loading unnecessary view
& record content client-side.
This improves performance for admins without the specific application
admin rights, but also fixes the main bugfix problem,
caused by the webclient querying name_get for the records in relational
fields content.
Example:
sale_management adds a res.config.settings field to specify
the default sale.order.template for the current company.
If a 'Settings' user without 'sale.group_sale_manager' opens the
settings, he won't see this setting, but if a default template is
specified for the current company, the webclient will still request
the name_get of this template to the server, because the field
was present in the view, only hidden with a groups attribute.
With this commit change in sale, the field won't be in the view unless
you have the Sale manager group, avoiding the error/traceback/bug.
2) Remove implied application administration groups
Do not force the specific application groups on all 'Settings' user,
they globally do not need those rights, and if they need it, they
can add it to their account themselves.
3) Add a test to make sure settings user are able to manage settings.
4) Enforce 'settings' -> 'access rights' -> 'internal user' groups
As the previous test highlighted some 'false positives' because
it considered a settings user unable to read `crm.team`
and `stock.warehouse` records, we also took the opportunity to enforce
the fact that 'Settings' & 'Access rights' users must be internal users.
It makes no sense for a portal/public user to have access to the
settings, and didn't work anyway.
Part-of: odoo/odoo#91909
Instead of having to repeatedly manually call `onchange_quantity` at
different points in the code, it is better to have it be computed
instead.
- Logic is left unchanged,
- onchange calls from other methods are removed, and
- tests are adjusted to properly handle compute. I.e. remove
'date_planned': datetime.today().strftime(DEFAULT_SERVER_DATETIME_FORMAT)
from when PO lines are created since this sometimes resulted in
inconsistent date_planned values for PO line and the PO date_order
(by 1 sec), which could lead to inconsistently created 'date_deadline'
values for stock_moves' created by PO line qty changes. Issue
previously didn't exist because onchange was not always called.
Part of Task: 2695116 (to avoid adding more onchange calls for new
feature)
Part-of: odoo/odoo#87656
This commit removes the call for tender feature via a
purchase.requisition. This feature is to be replaced with the ability to
directly compare prices/options of POs/RFQs within a PO to remove extra
steps to compare them. The linkage between POs previously provided by a
purchase.requistion is replaced by the POs being directly linked to each
other. Feature to auto-create call to tenders via a product option is
removed and the user is expected to know/be responsible for when they
should do a call to tender themselves.
All references to old Call to Tenders replaced with Blanket Order, and
we remove/rename the menu items since Blanket Order is now the only
purchase.requisition.type option (we expect minimal customizated types).
Follow-on refactoring to switch purchase.requisition to
purchase.blanket.order to come later. Follow-on refactoring to switch
purchase.requisition to purchase.blanket.order to come later.
Part of Task: 2695116
Upgrade PR: odoo/upgrade#3586
Part-of: odoo/odoo#87656
Purpose
=======
In message_notify, when called on a recordset, call model methods instead of
base one defined on MailThread. This allows to use internal methods overrides.
Also perform some linting on calls to ``message_notify`` in order to better
spot calls, parameters, ...
Task-2852908
closesodoo/odoo#92868
Related: odoo/enterprise#28038
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- Install puchases, accounting, contact
- Create a new company with a bank account
- Create a new person contact linked to the previous company
- Make a purchase order from that person
- Make a vendor bill using the auto-complete as the previous PO
Issue:
The bank account field is not filled
Cause:
The _prepare_invoice function tries to grab the bank information
from the contact on the PO. But in the case of a person of a company,
this information is stored in the parent company. Resulting in an empty
value
Solution:
Use the field "comercial_partner_id" to get the bank id. As this field
will use the parent company if the current partner is a person.
opw-2849706
closesodoo/odoo#93487
X-original-commit: c5f94e84dd5d6ec108484425d348053961bd13ff
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
SPECIFICATION
Various change for the partner view:
- Moved the activity widget to the bottom right of the kanban
- Moved the informations badge to the bottom right next to the
activity widget and made them clickable
- Change the address options order and add a small help below
- Change the 'Remove' button function from delete to remove from
the company and add a delete button to the right end.
- Correct some typo
- Add an 'Archived' ribbon to the kanban card
- Change various small things
LINKS
Task-2821356
closesodoo/odoo#89249
Related: odoo/enterprise#26442
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit contains the following:
1) Added sudo to product record when adding supplier info during PO confirm, so that
supplier info is created regardless of who is confirming the PO.
2) the test test_multicompany_partner_bank was removed since it was creating two
res partner banks with the same partner and setting company_id to two seperate companies
while currently the company_id is related to the company partner thus this can no longer
happen.
3) test_message_qty_already_received was changed to not set the company_id explicitly as
it caused unexpected cache miss in the runbot.
task : 2764771
Part-of: odoo/odoo#91640
Task 2833338
Add a smart button to show origin SO/PO on invoices and vendor bills.
closesodoo/odoo#90664
Signed-off-by: Steve Van Essche <svs@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>
Step to reproduce:
Install purchase
Create a purchase order
Set a vendo and a product that has this vendor in its
vendor list
Set a product name in the line of the vendor in the product
purchase section (you will need to add the field)
Change the description of the product
Change the quantity of the product
Expected behavior:
The description stay the custom input you just set
Current behavior:
The description is reset to its default value
Explanation:
When changing the quantity the vendor from the product vendors can change.
Then its vendor product name and code can change and thus the default
description in the purchase order. To solve that we need to differentiate
a custom description from a default one and only update the descritpion
when the quantity changes if the descritpion is a default one (and not a
sutom one)
opw-2827667
closesodoo/odoo#90923
X-original-commit: 96bbe252ecbb94600632a1a5cb449b8d2810d2c0
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@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>
Fixed the TestPurchaseInvoice.test_double_validation and the setupClass
to use test accounting data in setupClass instead of the demo data.
closesodoo/odoo#89370
X-original-commit: a7546aead36c5d56809fcd9c46b2a552991b5449
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Steps to repoduce:
- Accounting > Customers > Invoices:
select several invoices to send
- Action > Send & Print > (deselect Print) > Send & Print
Issue:
- It sends only one invoice per company
Cause:
- the mail_compose_message sets the status of an email as `cancel` when a mail has already been sent to a specific adress mail in the batch
Solution:
- If the use of mass mailing is document-based (e.g.: sending multiple invoices) it will allow to send multiple emails to the same adress
opw-2775121
closesodoo/odoo#88992
X-original-commit: f08685020f6a00d4e10e30ccbcf70c9eb1a764d5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Most of the extensions of `_name_get` are very similar and only want to
search for the given string in multiple fields.
A lot of extensions also don't take into account the negative operators.
Some implementations were also really outdated and needlessly
complicated.
closesodoo/odoo#86588
Related: odoo/enterprise#25608
Signed-off-by: Raphael Collet <rco@odoo.com>
Add a reception/delivery status on sale orders and purchase orders.
The idea is to have an indication in list view about the situation
of pickings linked to the SO/PO.
Inside the document itself, the quantity delivered decoration are
designed to indicate if everything is correctly deliver or if
it still something to do. (red if the delivery/receipt is late and
incomplete)
Task-2381757
closesodoo/odoo#63356
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Unify taxes computation between 'account', 'sale' and 'purchase' including:
- computation of price_subtotal/price_total.
- computation of business models total (using the json field)
closesodoo/odoo#80231
Task: 2654784
Related: odoo/enterprise#25620
Signed-off-by: Olivier Colson <oco@odoo.com>
Purpose
=======
Pictures from the digest emails are currently stored on the database
itself, meaning that if the database expires (e.g. after trial expires) all
pictures from previously sent emails won't be visible.
This is an issue since digest tips are meant as a marketing tool to bring
people to Odoo after trying a database.
Digest pictures are now taken from Odoo's server
(https://download.odoocdn.com/digests) so that the pictures will still
be visible after the database has expired.
From this commit onwards, it should not be allowed to change a digest
picture with the same name (to display a gif of a newer version), since
all databases with previous versions would receive pictures of a version
that does not correspond to theirs.
This also means that everyone client's Odoo server will contain pictures
that are never used. This could be fixed if Odoo stored them somewhere
else and didn't make them dependent from the git repository.
Task-2372195
closesodoo/odoo#87343
X-original-commit: 35157677a2a63a2559a72aff21e62e23a3c671a2
Related: odoo/enterprise#25654
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Nasreddin Boulif (bon)