product.product inheritS from product.template, and they both
define the 'standard_price' field, but implement it differently;
- product: the field is a company dependent one (so non stored)
- template: the field is a computed one based on tis variants
For the first case, since the field is not stored in database, when
doing SQL query, we have to get the value from the table ir_property.
That is what purchase report does, but instead of searching on resource
'product.product', it does it on 'product.template'. There are
obviously no entries in ir_property table for 'standard_price' field
on product template. As consequence, the "product value" (cost)
is always null in purchase reporting.
This commit fixes that by modifying SQL query to get the good
value from ir_property table.
By default, Chrome browser will block pop-up windows which will block
all actions from type act_url with a different target than 'self' (i.e.
'_blank').
This commit adds a check when such an action is called and sends a
warning in the web client when it fails to open. This mimics the
behaviour already present for the report actions.
In saas-11.2, the traceability has been rewritten and there is no notion
of upstream/downstream, also the code tested seems to have become dead
in some instance (in particular: the one this test tested), so will be
improved soon.
opw-1845444
closes#24887
* export benches for m2o
* tag benches instead of requiring editing the source to enable them
* dump the profiling stats intead of saving to disk (less convenient
for complex analysis but way more so for simple overview)
* add M2O benching in addition to the existing integer-based one in
order to expose problematic behaviour when exporting significant
numbers of non-shared relational records (& quantify impact of
creation v read)
Following odoo/odoo#22493 the performances of exporting XIDs was
greatly improved by batching XIDs and avoiding the ~3 SQL queries per
xid/record when no xid exists yet.
*However* the batching was done per call of _export_rows and to handle
relational fields _export_rows calls itself recursively leading to
sub-standard xid batching:
* for M2M and O2M fields, some batching would happen on a
parent-record basis, each M2M or O2M field (in a parent) would be
xid-batched, but two parent records wouldn't see their children
xid-batched together
* for M2O, there would be essentially no batching with a call to
__ensure_xml_id per record and while less queries than before in the
worst case more complex ones in fact
Change: rather than ensure XIDs exist when performing the export, add
XIDs export as a post-processing of the exported records table. This
way, each involved model can be entirely batched and exporting 10000
records's (id, value_id/id) 2 calls instead of 10001.
Also rename _export_rows's recursion parameter for clarity, it has
clearly outgrown its use as a batch invalidation flag and the name
is now less than clear.
Furthermore _-prefix & mandate kwarg usage to make it clearer it's not
really a "public" parameter, and is intended as an internal recursion
flag.
* store hashed passwords in the `password` column but gate it behind a
computed field
* make the password field essentially write-only (SQL aside)
* add a "plaintext" hash type so it's possible to set the password in
SQL directly & be able to login & have it automatically updated
Task 34211
This is a backport of commit https://github.com/odoo/odoo/commit/2f15a5fa647d55df36c9019df467802a3aa9b4e3
Purpose
=======
Add the possibility to create private addresses, only accessible for a subset
of users.
Specification
=============
- Add a new 'Private' partner type
- Add a res.groups in base 'Access to Private Addresses'
- Add ir.rules for the following behavior:
- Every employees/internal users can read non-private addresses
- Only users in group_private_addresses can access private addresses
- Add in base a simplified form view for private addresses
The following points won't be backported:
- A HR Officer is automatically granted in group_private_addresses
- Use the simplified form view to open the address_home_id form on employees
That's because it requires to update 'base' to make it work. If a user only
update 'hr', this will break his instance while 'base' isn't updated.
But these modifications can be applied manually quite easily.
Due to the switch from less to scss, changes were made. Especially, the
class oe_link is now 'deprecated' and interpreted as 'btn-link'. The
previous style defined on the latter removed the padding which breaks
the style when several buttons follow each other.
This commit should fix the style while maintaining the intended behaviour,
a vertical alignment between the button and the text inside the pane.
With this commit, it is now possible to delete a page directly from it's page
properties dialog.
Before this commit, you had to go into the page manager and then find your page
that could take some time.
task-1850578
Closes#24861
See https://github.com/odoo/odoo/issues/20804
We don't turn invoice_ids into a computed field, because we need it erverywhere for technical reasons. Instead, we use a new computed field only there to ensure consistency of the displayed data.
Was task: 1819501
Was PR #24290
When installing the website with a lang different than the one set
on the user, the button unsubscribe in the mass mailing snippets
didn't work because the unsubscribe link contains the code of the
language. The function send_get_email_dict in model mail.mail didn't
expect this behavior and so couldn't set the right unsubscribe link
in the mail.
opw:1850696
Remove wrong attr name '/shop/checkout' and add the action '/shop/address'.
It allow others routes to render the form, and that the submit form is handled
by the default checkout process.
Todo: make this 'action url' as an argument
Stable version of 65a589eb54 (reverted
at 935043dda1) that doesn't cause the
following errors:
odoo.modules.graph: module website_quote: Unmet dependencies:
sale_payment
on existing databases without sale_payment installed.
A downside of this approach is that sale_payment can be uninstalled
without uninstalling website_quote. Adding an uninstall_hook to
sale_payment could solve that, but it wouldn't warn the user
website_quote would be removed in the "Uninstall module"
wizard. Keeping in mind this is only a temporary hack for stable,
keeping sale_payment installed in this case shouldn't cause any
issues.
opw-1847977
It was very confusing for the user to distinct account.payment and payment.transaction. From now on, the transactions are
technical objects and, in the backend, we only refer to it in log messages (Front end will be adapted in the same fashion
later on). They are hidden in debug mode in accounting\configuration\payments as their purpose is now purely technical/log
This commit also aims to reduce the gap between the accounting app and the transactions: account.payment objects are
created/validated upon completion of transaction.
To ease the capture/voiding of pending transactions, the related buttons are now displayed directly on the SO/invoice
instead of the transactions.
Was task: https://www.odoo.com/web#id=35857&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
Was PR #24043
[FIX] add domain based on journal to payment tokens
Was opw: https://www.odoo.com/web?debug#id=1828206&view_type=form&model=project.task&menu_id=5200
In a warehouse, mostly most of the products have no lot. It stays
important however to avoid having old products in stock, certainly if
we can distinguish them by pack or location.
As now in stable, in_date is not put on the quant for non-tracked products,
databases might mix quants with and without in_date of the same product.
We should see those without in_date as the oldest.
That is why we need to be able to apply a ASC NULLS FIRST (ASC is NULLS LAST by default) for FIFO
or DESC NULLS LAST for LIFO.
In order to do that, we copied the code from the _search method of the ORM to
be able to do this special order as the orm itself is restrictive as it
supposes the order itself has no spaces.
We adapted and added some tests to check it handles the combination of NULL/NOT NULL well.
- Set up as a shipper with the highest priority one which will cause an
error (e.g. service not available for customer address)
- Order a product on eCommerce, go to Payment page
Nothing prevents to click on the 'Pay Now' button, although the shipper
rating has failed. Moreover, the error is not displayed in the label of
the shipper.
Workaround: we force a click on the selected default shipper to trigger
the update. The good solution would probably be to have a completely
dynamic shipper rating integration, instead of some processing at first
rendering and then extra dynamic processing.
opw-1838765
When we selected an image/icon, there was no visual feedback explaining
to the user that the image/icon had been selected (except for images on
chrome).
task-35020
Closes https://github.com/odoo/odoo/pull/24160
When clicking on button "Invoices" from a payment, it always displayed
the supplier views instead of taking care about the type of the payment.
opw:1849397
Purpose
=======
The method _name_search and _search add support to search as another user.
All the overrides of name_search and search redefine the behavior of the search.
This bring inconsistencies as the result of a call to _name_search and name_search
could differ on certain modules, which is not acceptable.
Specification
=============
Example:
~~~~~~~~
If the name_search method is overridden to search also on the driver name,
then calling name_search with a label 'JF' will return all the cars with a name containing
'JF' or all the cars with a driver name containing 'JF'. Let's say that we have a ir.rule
preventing a user to read the cars of another company. Then the call to name search only returns
the cars satisfying the previous condition AND belonging to his company.
Now, we want to overpass this constraint. We call _name_search with the attribute name_get_uid=1.
Then the call to _name_search returns all the cars from all the companies with a name like 'JF',
but nothing is done about the driver_name.
Example of wrong search redefinition on a model
-----------------------------------------------
@api.model
def name_search(self, name, args=None, operator='ilike', limit=100):
domain = args or []
domain = expression.AND([domain, [('name', 'ilike', name)]])
partners = self.env['res.partner'].search([('name', operator, name)])
if partners and name:
domain = expression.OR([domain, ['|', ('driver_id', 'in', partners.ids), ('driver_id', '=', False)]])
rec = self.search(domain, limit=limit)
return rec.name_get()
Example of correct search redefinition on a model
-------------------------------------------------
@api.model
def _name_search(self, name, args=None, operator='ilike', limit=100, name_get_uid=None):
domain = args or []
domain = expression.AND([domain, [('name', operator, name)]])
partner_ids = self.env['res.partner']._search([('name', operator, name)], access_rights_uid=name_get_uid)
if partner_ids:
domain = expression.OR([domain, ['|', ('driver_id', 'in', partner_ids), ('driver_id', '=', False)]])
rec = self._search(domain, limit=limit, access_rights_uid=name_get_uid)
return self.browse(rec).name_get()
The same logic should be applied on the overrides of the search method.
With this commit, we introduce a better screen to manipulate the search
view in a mobile device.
Note: most of this work was initially done by suh-odoo, then was adapted
and moved to community by myself.
task 31464
For historical reason, purchase depends on stock module. We now
plan to add purchase feature for services. A service company will
not be interessted by having stock install when they do service
purchases. So this commit breaks this dependency by creating a
new bridge module named 'purchase_stock'.
No functionnal behavior should have changed, this commit only
move code.
However, some points need to be highlighted:
* The purchase report was split, the same way sale report is. Installing
stock will just add a few addionnal informations to the SQL views.
* Since test cases depends on stock demo data, the basic purchase
addon does not contain tests, but this will come in futur tasks.
* consu and service product's receieved quantity can be manually edited,
when stock is not installed. The same mecanism to compute this quantity
done
in sale (for delivered qty) will be implemented later.
Thanks to @amoyaux and @pimodoo for their reviews.
Task #47927
When stock is not install and using purchase alone, user
should be able to edit received quantity manually for
consummable (and services) products.
This is a direct consequence to the split of purchase
and stock module.
We want to break the dependency between stock and purchase
for our furtur developpement. For more modularity, a new
bridge module 'purchase_stock' is created.
This commti move part of business code, views, data, ...
related to stock management from purchase into purchase_stock
without changing any feature.
Task #47927
The idea is to do like the sale report: being
able for other modules to extend the report and
add their own fields. As we are going to split
stock from purchase, we will need this.
Revision on 8ac98fc78a
The commit above does not check whether the list contains data or not.
As a result, if there are no data in the list, there is no reason to
fetch `name_gets`.
In fact, there could be a traceback because some parameters of this rpc
are computed from data in the list. So if there are no data in the list,
the parameters of the rpc are undefined. This was the case for a test
in enterprise.
Revision on https://github.com/odoo/odoo/commit/9a9da5763b38a3bce54e9c4870af0032e38cacc3
The intent of the commit above was to no abandon records in a list on
discard when these records have been created from a `default_get`.
Also, the `default_get` may also perform an `onchange` that could create
more records. The records from this `onchange` must also be included in
the "do not abandon" rule.
However, the rule was too relax, so that any following `onchanges` from
a user interaction was also considered into this rule. As a result, it was
not possible to abandon such records.
With this fix, we restrict the rule to `default_get` (already the case) and
only the `onchange` right after a `default_get`. Any record created on an
`onchange` from a user interaction after a `default_get` should be abandoned
on discard.
Representation of creating the list:
savepoint
|----------|-----------|-------||--------|------->
create default_get onchange1 onchange2
record in the list is created by default_get or onchange1
=> do not abandon on discard
record in the list is created by onchange2
=> abandon on discard
When seeing the work orders view, it would display an empty black box instead of
the proper message.
The message is not displaed since creation is deactivated.
opw 1839001
Have a delivery for a client, with pack operations
Connect on this user's portal
Go on the SO and then on the delivery
Before this commit, there was an Error 500
because access to fields of pack_operations was forbidden
After this commit, the report downloads well
OPW 1849520
closes#24849
datetime.date(year, month, day).weekday() is undefined for year > 9999.
When creating a google recurrent event that is set to never end,
Odoo tries to create 100 individual events.
If in Google calendar the user sets a recurring event to a custom interval,
of say a century, then the hundredth event is in 100x100 years, so in 12018.
Since 12018 > 9999, we get a traceback and synchronisation never happens.
opw 1845311
- Create the following BOM structure:
```
Prod 1 (Manufacture)
|
--- Prod 2
Prod 3 (Kit)
|
--- Prod 4
Prod 5
```
- The BOMs for Prod 1 & 3 must have a routing set, to generate
workorders
- Create a MO for 1 unit of Prod 1, process to the end
2 units of Prod 1 are created instead of 1.
This is due to the WO for Prod 3 not having a `next_work_order_id`.
Therefore, `record_production` adds an extra quantity at:
```
production_move.quantity_done += self.qty_producing
```
To prevent this, we set as `next_work_order_id` of the BOM of Prod 3 the
WO of Prod 1.
Closes#19527
opw-1817398
When we perform a planned transfer (which is the default behaviour now)
we are not able to set a quantity done on move lines in a confirmed
move because, the field 'is_initial_demand_editable' is true but should
not.
To fix this, we set 'is_initial_demand_editable' to true when it is not
a planned transfer AND the state of the move is draft, which is the
desired behaviour.
This behaviour come from rev:https://github.com/odoo/odoo/commit/ffb79761c1225c8a9c9303db4781f1b40b5d9944
jem-odoo