When opening a purchase order shipments using
the given smart button, and attempting a refresh,
it leaded to a "record has been deleted" error,
because the current `active_id` is a purchase.order
id, while the `active_id` in the window action
`action_picking_tree` context expects a picking type
id.
The purpose of using `action_picking_tree` was to use
it as a template instead of having to create a full action
dict, not to actually use it.
By removing the id from the action dict, we prevent
to re-use the action window `action_picking_tree`
on refresh.
opw-706933
Before this patch, it was not possible to manually process a pack (i.e.
checking the "is_done" box), because the field was always reset
*before* saving. It was still possible to process it by hitting
"validate", but it was not possible to put a pack in a pack.
Manually process a pack means hitting the checkbox "is_done" on the pack
operation. This "is_done" field is a boolean computed field with a reverse
function, and this reverse function set the "qty_done" on the pack
operation to 1.0.
The compute field doesn't have any depends declared, so the value was
invalidated after any changes in the form view. The computed method was
used to check the checkbox is the "qty_done" is set to 1.0. It was
probably used to check the checkbox when opening later a picking for
which the pack was already processed.
The issue is that the "qty_done" was never updated, because the inverse
method is only called when saving, and the compute method already reset
the "is_done" field to False, as the "qty_done" was not updated.
To fix this issue, we do not use an inverse method but an onchange.
Indeed, this was the expected behavior: hitting the checkbox should
change the "qty_done".
We already have a test covering this use case, committed in v9 [1]. It
didn't discovered this regression because the test was using directly
the "qty_done" field on the pack operation, not the "is_done" field used
in the view. We change the test to use the "is_done" field and manually
trigger the onchanges.
This is due to a bad new API migration [2].
[1] rev e248420348
[2] rev d8548e0771
There was a traceback error while installing the indian accounting module.
The commit 9c77467f07 shouldn't have been forwarded.
This cancels some account tag ids modifications from the commit 500b73323d. (this commit refactors the account tag id numbering)
This implies that some st_tag_in_[0-9]* point to an old references that no longer exist and return an error.
To fix this problem, we replaced the old(canceled) account tag reference by those after the refactoring in saas-14.
- Buy only a free product with digital download content
- It is not possible to access the download link
Since the product is free, there is no invoice created. Therefore, the
product is never considered as paid.
opw-705258
The account move line filter 'Unreconciled' only takes into account the
matching number. We should also make sure the 'reconciled' boolean is
false, since a line with a zero amount (e.g. invoice with only a free
item) is considered as reconciled and should not appear in the list.
opw-705982
One can add an item in a Many2Many without creating it, so the action
should be available. However, if the create action is not allowed, there
is no 'Create' button in the SelectCreateDialog.
The xml file with the cron that creates the recurrent
preventive requests was not loaded in the system, so we needed to add
it.
Before, the cron was foreseen to only create the maintenance request on
the day that the request was foreseen (in the morning). Now, it will
create a request if none exists on the next_action_date. That way the
requests can be planned for.
The other problem is that the '_compute_next_maintenance' method
for calculating the next_action_date does not take into account
the possibly manually already created requests. So, now, the next
maintenance is calculated with the closed requests and the open ones.
If the first new one is in the past, it takes that date in the past. If it is in
the future, it will see if the gap is big enough to put a maintenance
in between the last done maintenance (or now) and the first new one.
If none exists, it is today + period.
That's why we have to add the 'request_date' in the depends. And take
into account the preventive requests existing on an equipment.
Before this commit, when opening a field chain with a field selector
and only removing parts of it and closing, the field selector was not
notifying the change.
Since commits 2a8a17024d and 9c68bc7482,
the session is not started by the webclient anymore but directly by the
session service instead, and the session info is found in the DOM
instead of by RPC.
Because of that, the session is started in the frontend and other
non-backend environments which caused a JS error while trying to
load qweb (as no qweb has to be loaded). This commit makes the
session start check if it is a non-backend environment and only
initialize session info (from DOM) in that case.
With the user who is trying to access and the record they are trying to access
to.
This way it is easier to understand the reason of the error.
Do not show record and user ids in the popup as it is a technical information.
Closes#13030
Ironically, clicking on the dropdown arrow of the field selector was
the only way which was not opening the dropdown. It was indeed added
as pure design element.
This commit handles the opening and closing of the dropdown in a more
robust way... while simplyfing the code too.
The product.template displays the list of pricelist items with the name of the pricelist
The product.product displays the same information except the pricelist name.
This commit harmonize both views to display the same information.
Fixes#15009Closes#15010
In debug mode the buttons "export unpaid orders" and "export paid orders" now
work. On first click, they prepare the file and display the download link. On
second click, the file is downloaded.
The error popup uses the same method to download the traceback.
Use a different icon to have a visual feedback why that 2 clicks are needed.
This 2 steps is required as it is not possible in most browsers to simulate a
click event on a link.
The download method is kept for backward compatibility but will be droped in
master.
In the next version, a proper popup will be integrated (cf #14365)
Closes#15322
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
The POS uses FastClick to circumvent the 300ms touch delay implemented
by browsers before a click event is fired. (Although this has since been
removed, probably we can get rid of this in the POS at some point as
well [1]).
The way FastClick works is simple: immediately fire a synthetic event
and block the one fired by the browser 300ms later.
Recently, browsers have started to only trust native events to trigger
default actions [2][3]. Chrome in particular has started not trusting
synthetic events since v53.
FastClick provides a solution for this with the needsclick class. It
will not interfere with events triggered on elements with this class.
[1] https://developers.google.com/web/updates/2013/12/300ms-tap-delay-gone-away
[2] https://w3c.github.io/uievents/#trusted-events
[3] https://www.chromestatus.com/features/5718803933560832Fixes#14886
- Create a manufactured Product A (sold as kit), invoicing based on
delivered quantity.
- Create the associated BOM, e.g. contains 2 Products B.
- Create a SO with Product A, validate
- Change the BOM so it contains 2 Products C
- Validate the picking linked to the SO
The delivered quantity is not updated since the delivered products (B)
are not the same than the products of the BOM.
This should not be the case. Changing a BOM should not affect the
invoicing. To solve this, we simplify the check and only verifies that
all moves are done.
The same change is applied for PO.
To be triggered on the fields that are used inside the computed field.
Was not very problematic before as the fields were not stored and recomputed
at each modification. It could be backported if needed.
Next commit will store these fields for performance reason, fixing the trigger
first is required.
Linked to #15259
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
Former implementation tried to retrieve the model in the 'model' and
'res_model' attributes of the widget, but both of them were undefined.
The model being required for some of the RPCs performed by the widget,
there were bugs (e.g. the messages weren't refreshed after the creation
of a new activity).
If a database had no base module or no latest_version, mark it as incompatible.
This should not happen in standard but as we are considering local databases
that may be non-odoo, we should be more fault tolerant.
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
Use Case
========
In the coupon module, a call to a write, a create or an unlink on a sales order line may trigger a write, a create or an unlink on another line. Example: I have a promotional offer "If you buy for more than 100 euros, you got a 10 percent discount on the sales order. On my sales order, I buy 2 imac at 999 euros. At that moment my total amount is over 1000 euros and I got another line, the discount. I write on the sales order line that I only buy one imac, a unlink is trigger on the reward line to remove it from the sales order.
Current Solution
================
At the beginning, I was overwriting the write, the create and the unlink methods on the sales order line to perform the correct actions according to the promotional offers that were still applicable, not applicable anymore of newly applicable. This solution was followed by side effects on the computed fields. For example, a write on the SO line that was triggering an unlink on another line was triggering a computed field that depended on the sales order line. In that case, the environment I received on the compute method was the environment before the line unlink. As the compute method was looping on the sales order line, it was taking values on a line that wasn't existing anymore and that way it was triggering an 'This record doesn't exist or has been deleted' error.
After a discussion with @rco-odoo, we realized that the only way to achieve this was to override the write method on a sales order to avoid quadratic computation loop when creating/editing/deleting sale order lines. As coupon are recorded as sale.order.line, it may effectively blow up.
We also overrode the create method on a sales order line to make an ORM command on the sales order instead of a simple create on the sales order. See: https://github.com/odoo/enterprise/blob/saas-14/sale_coupon/models/sale_order.py#L253
For the write and the unlink, this is a little more complicated because a write may trigger a write and an unlink may trigger an unlink, resulting in an infinite loop.
New Solution
============
Having a method _recompute_coupon_lines on sale.order. This method do nothing if there is a key coupon_recompute in the context.
```python
@multi
def _recompute_coupon_lines(self):
if self.env.context.get('coupon_recompute'):
return
self = self.with_context(coupon_recompute=True) # avoid loop
[...do actual stuff...]
```
The create/write/unlink method on sale.order.line call super before calling the method _recompute_coupon_lines
```python
@multi
def write(self, values):
result = super(SaleOrderLine, self).write(values)
self.mapped('order_id')._recompute_coupon_lines()
return result
```
In order (pun intended) to accelerate mass creation/edition of lines, the method create/write/unlink of sale.order should call recompute themself
```python
@mutli
def write(self, values):
result = super(SaleOrder, self.with_context(coupon_recompute=True)).write(values)
self._recompute_coupon_lines()
return result
```
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
Nicolas Lempereur