Most people install the im_livechat module and expect it
to be enabled automatically on their website.
When it doesn't work they try to use the integration JS
code and add it to their website layout, which does not
work as expected.
Setting it as auto-installed solves the issue.
* Failing test for one2many [(5,)] action, when domain is callable.
The problem is that `self` inside a callable domain becomes the comodel when at [(5,)].
* [FIX][fields] Make [(5,)] with computed domain work.
To reproduce this failure, declare a field like:
```
child_ids = fields.One2many(
comodel_name="other.model",
domain=lambda self: [("id", "in", self._ids_to_find())],
)
```
Now set some value to it.
Now unset them. Impossible because ``self`` becomes ``other.model`` in domain evaluation.
Web client use fields_get (which one call get_description) to know if
a group operator exists. But until now, group_operator are never returned.
Without it, the web client cannot display the sub-total except for sum
(the fallback in the web client).
This commit closes#13713
Todo: do the same on Class Monetary in next branch
According to the documentation it makes sens to map an excluded tax
with an included tax. For example in Belgium, B2C taxes are generaly
included and B2B taxes are excluded. Then we can manage this situation
by creating a pricelist with prices for B2B and B2C.
opw:688085
When an analytic account is specified on a write-off move, it should be
written on the move line linked to the write-off account, as it was the
case in v8.
opw-688635
When importing an action rule, an error occurs:
- The import is committed when the user clicks on "Validate"
- The import fails with a traceback when the user clicks on "Import"
This is because commit 7d648542 introduces a `cr.commit()` in the
`_update_registry`, while nothing should be committed upon import
validation.
opw-683874
The field bank_statement_id was removed at c04065a
The rule is no longer working and we have no link between a cashbox and a bank
statement anymore.
Fixes#13550
On old apple devices (IPad 2, IPhone 4, ...), the FAQ Roller could not
be opened on click. This is because the snippet does not use standard
bootstrap correctly and put the toggle on a <div/> element instead of
a <a/> element.
This fix forces an empty click handler on these <div/>, which allows
standard bootstrap to work.
These data should be in no update. Else at next update, it can change the configuration
of the production.
This commit closes#13404
Courtesy of @bealdav
Since Chrome 53.0.2785, the input select is hover the existing tag.
With this fix, the existing tag are displayed at the right side of
the input to create a new one.
This commit closes#13655
Courtesy of @8cells
When a user registers for an event on the front-end, the confirmation of
the associated SO will also confirm the registration. However, if a SO
is created manually and a ticket event is added to it, the confirmation
of the SO will not trigger the confirmation of the registration.
In the second case, the registration simply doesn't exist yet at
confirmation and is created by the method `default_get` of
`registration.editor`.
We make sure to confirm these registration when we make the final
reservation.
opw-688665
An issue occurs in the following situation:
- Define a currency exchange rate at day 1 and day 2
- Create an invoice at day 1, and calculate the taxes. Do not set an
invoice date!
- Validate the invoice at day 2
The exchange rate for taxes is the rate at day 1, while the exchange
rate for other amounts is the rate at day 2.
There is actually no way to know what was the rate applied for the
taxes at invoice validation. There are two solutions:
- recompute the taxes at validation
- force the user to set an invoice date and recompute manually the
taxes
The first solution might have unexpected effects, therefore the second
solution is applied.
Fixes#13473
opw-688517
In a multi-company environment, we need to make sure to copy the company
of the PO to the company of the picking. Otherwise, it might happen than
the PO as a different company than the picking.
Closes#13129
If a model uses nested sets to maintain a hierarchical record
ordering, then bulk inserts (e.g. via a CSV import) are likely to
suffer from an O(n^2) performance penalty, since there is a high
chance that each new record will require many of the existing records'
parent_left and parent_right fields to be updated.
The context parameter 'defer_parent_store_computation' may be passed
to the load() method, in order to defer updating the parent_left and
parent_right fields until after the bulk operation is complete. This
appears to have last been fully supported in version 7 (via the old
import_data() method).
It is still possible to specify 'defer_parent_store_computation',
e.g. via an XML-RPC call such as
m.execute_kw(dbname, uid, password, 'stock.location', 'load', [],
{'fields': fields, 'data': data,
'context': {'defer_parent_store_computation': True}})
This will currently defer the recalculation of parent_left and
parent_right, but does not correctly call _parent_store_compute()
after the bulk operation is complete.
Add the missing call to _parent_store_compute() to perform a one-time
update of the parent_left and parent_right fields if needed after the
import operation is complete.
Also fix the child_of_domain() and parent_of_domain() expression
methods, so that the 'child_of' and 'parent_of' operators give correct
answers when updates to parent_left and parent_right have been
deferred.
Signed-off-by: Michael Brown <mbrown@fensystems.co.uk>
Closes#13688 (part 2/2)
The expression context is currently passed to to_ids() but is missing
from all calls to child_of_domain() or parent_of_domain(). These
methods are effectively always passed a context of None.
Signed-off-by: Michael Brown <mbrown@fensystems.co.uk>
Closes#13688 (part 1/2)
It wasn't possible to cancel a purchase order
within the state "Waiting for Approval", despite
the fact the button cancel is displayed.
Clicking on the cancel button just did nothing.
This is now properly working, thanks to the additional
path added by this revision, between the workflow states
`CheckForApproval` and `cancel`.
opw-688685
Bulk inserts of product definitions (e.g. via a CSV import) will
suffer from an O(n^2) performance penalty due to an unfortunate cache
invalidation bug. The underlying cause is difficult to determine due
to the labyrinthine nature of the relationship between product.product
and product.template, but some key elements are:
- The "product_variant_count" field is a non-stored computed field,
and so gets invalidated by the call to recs.modified(upd_todo) in
BaseModel.create()
- Field.determine_value() will call _prefetch_field() to repopulate
"product_variant_count" by refetching all records from the database,
despite the fact that "product_variant_count" is not stored in the
database.
Using the length of "product_variant_ids" directly (instead of going
via "product_variant_count") seems to avoid this problem, possibly
because the definition of "product_variant_ids" conveys more
information about the circumstances in which its value must be
invalidated.
An alternative solution of making product_variant_count a stored field
(using the same trigger as for other variant-derived fields such as
volume and weight) works but still results in some unnecessary fetches
and invalidations.
Signed-off-by: Michael Brown <mbrown@fensystems.co.uk>
Closes#13689
In saas-12 and up, upstream_dependencies returns:
- when called from old API : a list of ir.module.module ids
- when called from new API : a recordset of ir.module.module
From 9.0 to saas-11, when called from new API it would also returns a
list of ids which can bring needless inconsistencies.
With this commit when called from new API a recordset is returned.
opw-690015
Also restrict XML data attribute evaluation context
even for real module data files. This will prevent
accidentally depending on context parameters that
would not be available inside base_import_module.
Move code related to redirection in its own class method. This way all
controllers perform their own actions and checks before calling the
redirection itself. Moreover it is necessary for some controllers to be
able to call the redirection independently outside of the mail/view
controller scope.
This commit also fixes some links generated for mail notification email
buttons. Assign and (un)follow buttons now effectively use the link helper
when generating the associated URL instead of manually crafting it.
Custom routes for notification buttons used in HR and CRM are added.
Indeed in order to be able to fine-tune the behavior called by those
buttons, using dedicated controllers is simpler than trying to use
a generic one. As there are few custom buttons in notification emails
using dedicated controllers does not lead to a code overhead.
Also restrict XML data attribute evaluation context
even for real module data files. This will prevent
accidentally depending on context parameters that
would not be available inside base_import_module.
When receiving new mail (not replies) to an alias we should not take
case into account.
This also homogenize the treatment of local parts. For instance, lines
967 and 980 convert the local part to lower case to avoid
case-sensitivity issues.
Also `mail_alias` normalizes alias names by lowering case and finding,
if necessary to make it unique, a suffix to alias name provided.
From RFC 5321, section 2.4:
> Exploiting the case sensitivity of mailbox local-parts impedes
> interoperability and is discouraged
Closes#334Closes#13037
On a given instance with 600 000 stock.history, the query changed by
this commit takes:
- before this change => 32 minutes
- after this change => 20 seconds
opw-685747
Purpose of the code is to automatically add the recipients of quotation emails
as followers. It is done using the mail_post_autofollow context key. However
current code add the context key in all cases and not just when composing
a message on sale order.
Following commit 6006c0d72a, the shipping address can be changed after
the call to `checkout_form_save`. This is the case, for example, when
the user has the same shipping and invoicing address. We need to make
sure to recompute the fiscal position after the shipping address is
finally set.
opw-689281
An issue occurs in the following case:
- create a SO
- set a partner for which a fiscal position applies
- change the partner to a partner for which no fiscal position applies
The fiscal position set in a first place remains. This is a major issue
when interacting with the eCommerce, since a fiscal position can be
first set based on the GeoIP results, then might need to be removed when
the user fills in his address details.
opw-689281