When setting a report with a `report_name` without dots,
the associated views button raised an exception.
This has been introduced during the migration to the new API
at revision 47c67b640b
Before, a try/except made sure the exception to not raise
the exception in case the report name could not be split
in two parts.
In this revision, instead of doing the try/except,
we check if the result of the split has a minimum
length of 2.
opw-706343
Following commit 1a1efe3fce, the module has some troubles to work
correctly. For example, it's impossible to get the download link in the
frontend of an attachment when the product was bought and paid.
Not really a big deal, but just in case the client wants to download
what he bought, we add back the link in the eCommerce.
A more complete fix will land later in master branch.
opw-705725
On the CRM dashboard, the shortcut 'exp. closing' is the same than the
'overdue' shortcut. However, the number of opportunities in these
categories is computed differently (see method
`retrieve_sales_dashboard`).
We introduce a new filter "Overdue Opportunities" which reflects this
difference.
opw-704173
The `log` method of a server action uses the same cursor than the
transaction. Therefore, if an error is raised during the server action
execution, the log messages are lost since the transaction is rolled
back.
We introduce a new cursor in the `log` method, so the log messages are
kept even when an exception is raised.
opw-704036
With how the chat manager was currently started, the "Odoo Session
Expired" could cause an arcane js error which would overshadow it.
This is caused by doing an RPC request too soon which invalidate the
session too soon which disable web client `show_application`.
With this commit, we have the error message "Odoo Session Expired"
instead of:
"Uncaught TypeError: Cannot read property '$el' of undefined"
closes#15313
opw-706346
This record rule added in the below revision:
1950fc4216
has been removed for an unknown reason during the account refactoring
c04065abd8
Without this rule, a user can see invoices from other companies
through the invoices analysis.
opw-705718
The search on qty_available was refactored twice:
- b9853db8 to split the method
- a989680b to remove the eval operator
At b9853db8 the order of evaluation introduced a bug so that the domain
('qty_available', '=' 10.0)
was evaluated
if product[qty_available] = 10.0:
which crashed (`=` instead of `==`).
Before b9853db8, this code did not crash as the operator was converted via
if operator == '=':
operator = '=='
which is no longer executed after the split
a989680b replaced the eval by a dictionnary that replaced the eval error by a
KeyError when searching with `=` operator.
This commit changes several things:
- replace the `operator in ('==', '>=', '<=')` as this was evaluated before the
operator replacement code mentionned above
- remove the replacement code as no longer justified since a989680b
- replace the OPERATOR key `==` to always match given key
This is related to revision
52db42d3df
The total sent to the `compute` method is always
within the invoice company currency, not
in the invoice currency.
`total` comes from the first tuple result
of the method `compute_invoice_totals`,
which is always in the invoice company currency.
if the company currency is different than
the invoice currency,
the total is the sum of the `line['price']`
converted to the company currency, as stated
by
`line['price'] = currency.compute(line['price'], company_currency)`
and
`total += line['price']`
In the above revision, the possibility to pass
its own currency in the context is added. This is in case
the payment term used comes from another company
than the one of the invoice (see the commit message of the revision).
The mistake was to use the invoice currency, while it should
use the invoice company currency, as the `total` amount is
within the invoice company currency, not the invoice currency.
opw-705604
A byproduct is a produced when producing another product (the targetted
product).
A move can be linked to another move. eg: we could have a manufacturing
order of 3 units linked to a move of a delivery order of these 3 units.
If we produce 2 units, the manufacturing order is split in 2 units and
1 units, and the delivery order is split similarily because of the link
1. [T manufacturing move split] -> [T delivery move split]
(T is the targetted product, B is the byproduct)
But in 8c307d7b1 a move_dest_id of a byproduct was linked to the targetted
product delivery move, thus in some situation the move of the delivery
order of the byproduct would erroneously be split 2 times instead of one.
1. [B manufacturing move split] -> [T delivery move split]
2. [T manufacturing move split] -> [T delivery move split]
This could also be the source of other issue, and since the byproduct
and targetted product are different, the link should anyway not be done.
opw-697151
note: this change is already in 10.0 (it is inside mrp refactoring 2ddc35a53)
The field 'Type' should always be readonly since:
- it must not be changed for standard models
- its value must be 'Custom Object' for a custom model
opw-706130
The field 'Type' should always be readonly since:
- it must not be changed for standard models
- its value must be 'Custom Object' for a custom model
opw-706130
When editing translations, you were not able to copy/paste texts before
this commit. Indeed, in some contexts, in some browsers, copy/pasting
text was creating a new paragraph inside the translation, preventing it
to be saved.
This commit simply adds code to remove these paragraphs each time text
is changed.
A more elegant solution will be found for master with website and
editor improvements.
When the quantity on hand is updated from the wizard, it may result in
completely inconsistent results.
This happens for example in the following case:
- 10 Units in Stock/WH
- 18 Units in Stock/WH/Shelf 1
The "New Quantity on Hand" suggests a theoretical quantity by taking
into account the location and its sub-locations. It the example, that
would mean 28 Units in location 'Stock/WH'.
However, the `_get_quants` method of the `stock.inventory.line` model
doesn't take into account the children locations. Therefore, the
theoretical quantity would be 10 Units in location 'Stock/WH'.
This inconsistency confuses the user, and the new quantity added might
introduce unexpected results.
opw-703886
Before this commit, when saving the pivot state in a favorite filter,
then restoring it, the row groupbys were ignored. This commit makes
sure that we take them into account if necessary.
Before this commit, when changing measures from the favorites menu (by
selecting a filter with some pivot_measures), the measures in the
dropdown menus were not correctly updated.
This commits make sure that we update the active measures in the menu after
each changes coming from a do_search.
In some instances we could want to access the barcode without being
connected.
For example if we print the report in an scheduled action, the report
would be rendered by wkhtmltopdf as public user making the barcode
blank (we have a redirection to a html login page instead of the image).
A solution requiring view updates in stable version was implemented with:
https://github.com/odoo/odoo/commit/14282f165 in 8.0 ( further explained
in https://github.com/odoo/odoo/issues/10621 ).
This commit fix this another way in 9.0 by making the barcode route
public since this doesn't bring any harm, solve this issue and allow the
use of the barcode route for public user (which might be wanted).
opw-694470
The GeoIP resolver keeps a permanent open file descriptor on the
GeoIP database file, for example /usr/share/GeoIP/GeoIPCity.dat
Because we initialize a resolver for each registry, servers with
many databases may easily blow up the open file descriptor limit
of multi-threaded workers (gevent or no workers multithread mode).
The Maxmind GeoIP API appears to be thread-safe since v1.1.4, so
it is much less wasteful to use a shared resolver for each process.
This patch keeps the _geoip_resolver class attribute on `ir.http`
for compatibility, but it will be removed for the next version.
A couple of places in the processing of bounces only
accepted a single matching partner. But there could
be multiple partners matching an email address, and
we should handle them all.
There might also be no matching `bounced_thread_id`
matched by the regex, so we should guard against a
bounced_thread_id == None.
It used to be based on owners, but owners are automatically
followers. Restricting on followers makes the visibility
of equipments and requests consistent with the mail notifications
linked to them.
Avoids issues with "phantom notifications" that appear in the
inbox counter but aren't visible.
- Enable lot tracking on Product A
- UoM of Product A is kg, but Purchase UoM is lb(s)
- Create a PO for 200 lb(s) of Product A, confirm
- Go in the picking: 200.01 lb(s) shuold be received according to the
pack operation, while 200.00 lb(s) are expected in the stock move.
The field `product_qty` on the sotck move contains the quantity in kg,
but already rounded from the value in lb(s). If we convert it back to
lb(s), there might obviously be a rounding error, since we do:
lb(s) -> kg -> lb(s)
To solve this, we recompute the quantity in the UoM of the product
without rounding, as a temporary computational value.
opw-705259
- Enable lot tracking on Product A
- UoM of Product A is kg, but Purchase UoM is lb(s)
- Create a PO for 200 lb(s) of Product A, confirm
- Go in the picking, specify the lots.
- Validate, and error: 'You have a difference between the quantity...'
This is because `lot_quantities` contains the quantities in kg, while
`operation.product_qty` is in lb(s).
opw-705259
`model` field of `ir.model` may be used as related stored field.
Marking it as modified force recomputation of these, even no change
occurs (by definition).
It is not possible to import Google Drive slides which are not publicly
shared.
Google Drive requires an access authorization from the user, not a
simple API key. The access token is generated in module `google_drive`,
but the latter is not in the dependencies of `website_slides`.
opw-703750
Proxy.load is required by the livechat when it is embedded in an
external page, so that it is able to get the static xml files
(with the correct base_url).
opw-706497
The original issue is the following:
- Configure the warehouse in Pick + Ship
- Activate the packs
- Create a SO with a product which is a consumable
- In the picking from stock to out, add the product in a package, and
validate.
- In the picking from out to customer, the previously created package is
not accessible/propagated as it would be with a stockable product.
The core of the issue is that there are no quants reserved for a move
linked to a consumable product. Since the package information is stored
on the quant, the package cannot be propagated correctly.
The fix is therefore to add the quants reservation feature on consumable
products, but only if the move is propagated from another one (i.e. the
move has ancestors).
That solved our issue, but also makes the workflow more logical. Without
the fix, all pickings are "Available" when created, even though one is
linked to another.
opw-702632
1. Activate the variant option on sale settings
2. Create a product and set invoicing on delivered qty and make it a
stockable product
3. Create 2 attributes, like color red and color blue
4. Odoo creates 2 variants
5. Make a BoM on the product with color red (So on Bom select the
product template and the product variant)
6. Set the Bom as "Ship this product as a set of components (kit)"
7. Now create a sale order with sale order line for the product variant
BLUE
8. Delivery order is created, deliver the whole delivery order
9. Go back to sale order and see that delivered qty is not updated and
thus we can not invoice the lines
opw-706423
The 'Start here to discover Odoo' is a data to help users to use Odoo.
Once they have understood, user often delete it but it comes back after an
update. The only way was to archive a record.
Using forcecreate is another way to avoid recreating it after an update.
Fixes#15262
Description of the issue/feature this PR addresses:
This commit adds the recompute conditional clause in the ORM unlink method.
This behaviour is already present in branch 10.0 as it can be seen in line 3431.
With this, the possibility of disabling the automatic recalculation of computed fields is given back to the developer of custom modules in performance critical scenarios. By using the Environment class "norecompute" context manager, the developer can now unlink records in a very fast manner and afterwards, execute the computed fields manually if needed (via an explicit method call or a direct sql update).
Current behavior before PR:
Having this option in the ORM will allow to speed up the system if needed when massive collateral changes must be made. One of this scenarios has to do with the modification of one2many fields and the write_uid and write_date computed fields. In the account module for example, when unreconciling account move lines, the deletion of the partial reconcile records involved in the reconciliation triggers a one by one update of the related account move lines and account moves. If the involved documents are big, such an account move (Journal Entry) with thousands of lines, if one of its lines is reconciled and afterwards unreconciled, the process can take several minutes due to expensive one by one recomputations such as the ones involved in the modification of the write_uid and the write_date in the models.py recompute() method. This modifications can however be enforced later with a couple of SQL update statements, instead of thousands of them executed by a for loop.
Desired behavior after PR is merged:
Developers of custom modules will now have the possibility of disabling the automatic calculation of computed fields, as it can be done in the create method (models.py "_create()" line 4370). This is vital for performance reasons, specially when handling big documents such as thousands of lines account moves or sales orders.
This is basically a backport of revision f259e74f8a
Complements the patch in 4715d18e12
in order to properly bootstrap a writeable data_dir when it is
(partially) nonexistant.
Depending on the startup parameters the data_dir might otherwise
have ended up read-only, preventing the creation of its necessary
components (session store, file store). Only the `addons` directory
of the data_dir needs to be read-only by default.
When validating a new order in between the create_from_ui RPC call and
the corresponding callback this new order was lost. There were two
reasons for this.
First of all, the Mutex supposed to prevent multiple create_from_ui RPC
calls from happening at the same time did not return a Deferred. This is
problematic because this function gets passed to jQuery.when() which
will consider functions that do not return a Deferred to be resolved
upon return.
Secondly, the resolved callback of the create_from_ui RPC call naively
deleted all paid orders, assuming they were all successfully sent to the
backend. This is not the case when an order is added to the orders array
in between the RPC call and the callback.
Closes#15190
Denis Ledoux