Every time the user updates a message, the js code triggered a rpc to
refetch messages in the current channel. This is useless, since the new
messages have been fetched anyway by the bus.
The 'string' attribute for both needaction_partner_ids and needaction fields
was 'Need Action'. This was problematic for example in the custom filters of the
searchview as it looked like the same field was appearing twice.
Update mail.pot as well.
A PlannerDialog does not extend Dialog for historical and graphical
reasons. Thus sometime a logic in Dialog is missed in a PlannerDialog
whilst it is useful.
In this instance, when doing an action from the planner which destroyed
it, the modal backdrop was not removed by bootstrap. Bootstrap does this
when the modal 'hide' function is called.
opw-653734
Issue: if the currency is before the value and we try to add a number at the begin of the value, the number is not saved (because the browser insert the number before the span).
Add a onEnableEditableArea in the rte to change the contenteditable value and the default behavior.
When a partner is created, the fiscal position is set automatically if
possible. This is not correct, the fiscal position should only be set
automatically on a SO, based on the delivery address.
Here is a scenario explaining the reason:
- Create 2 fiscal positions, one in US and one in Canada. Both fiscal
positions apply automatically depending on the country.
- As an non-logged user, go in the web shop
- Buy a product
- At the checkout phase, the Billing Information are in US, but the
Shipping Information in Canada.
- The fiscal position which will apply will be US, while you expect it
to be Canada
The reason is that the fical position which applies is the one on the
parent partner (US in this case), since all children partners must have
the same accounting data.
With this fix, we simply remove the automatic setting of the fiscal
position on the partner.
opw-653072
When creating a calendar event with all_day=False, the fields 'start' and
'stop' did not have to be set by onchange_dates due to a bad datetime format.
Then the function used to set fields 'start', 'stop', 'start_date' and 'end_date'
must be onchange_duration(only used when with all_day=False).
This function has been introduced by b7e393a.
opw:653045
The installation of these modules must not require
the installation of the full accounting,
the module `account_accountant`.
- base_iban: This is a dependence of multiple localisations
be, ca, de, do, ec, es, fr, gr, it, lu, nl, no, pl, si, uk, vn
installing the invoicing with these localisations must not
require the full accounting.
- account_check_printing: `l10n_us` depends on it, and this localisation
must not required the installation of the full accounting.
In this case, even if `account_check_printing` is installed,
the configuration for it won't be available, there won't be any menu
for it, but this isn't a matter, as checks are supposed to be used
for purchases, and invoicing is supposed to be used for sales only.
opw-653271
As everywhere else, dates & datetimes must be formatted according
to the format defined in the `res.lang` of the user, and within
the timezone of the user.
Before this revision, when adding a datetime field to a calendar view,
the raw value of the date was displayed, for instance:
`2015-01-01 10:00:00`
instead of
`01/01/2015 11:00:00`
for a user in English(US), in UTC +1.
fixes#5324
opw-653625
Closing a task associated to a sale order line requires
the write access to the according sale order line, that
a user who is only a Project > User does not have
by default.
Fixes#9286Closes#9352
request.website.user_id corresponds to the public user, while we want to
select the default pricelist of the connected user.
Moreover, if the connected user doesn't have the appropriate access
rights, it will cause a Forbidden Access error.
opw-653792
When confirming a sale order through the ecommerce
(at payment, most of the time),
the confirmation email should be sent at confirmation.
This is the subject of the revision
809e1a6081
that was lost with revision
94716a3f14
At the moment, the email was sent only for
orders not being automatically confirmed
(transfers, for instance).
opw-653800
This reverts commit cd7d73a9a5.
This was mistakenly forward-ported from 9.0 in
0a07be8190. Rescue sessions only exist in
9.0, they have been completely removed from both master (in
23d7caa8d5) and thus saas-7.
If the delivery method chosen is NOT an external provider (such as
Fedex, UPS...), the shipping cost is not set on the delivery order.
This fix will search for any shipping cost on the associated sale order
and will update the shipping cost accordingly on the delivery order.
opw-653328
When clicking on button "add_to_cart" for a product with several options,
the user must be redirected to the product page. In this way, the user can
choose the options, he wants to buy with the product before adding the product
in the cart.
opw:653356
Currently, the button "Send Email" next to the email address of an event
registration didn't work if a partner was not set.
This commit removes the button, thus removing the feature but partially
adds it back via the chatter suggested recipients in the same way it is
done for a lead.
It is still partially a feature regression since to work the viewing
user need more access rights (e.g read access right on res.partner)
than before.
closes#9486
opw-653127
If the invoicing policy of a PO is set to "Based on incoming shipments"
and the PO contains a product of type "service", it is never considered
as invoiced, and therefore reach the state "Done".
The reason is that no stock move is linked to this PO line, and
therefore it is never considered as invoiced since we check the invoice
state of the associated sotck moves.
This fix assumes that in this specific case, a PO line for a service is
always invoiced, since there is anyway no incoming shipment linked to
it.
opw-654317
This revision is related to a9d20d9fa0.
`dataset.cache` contains an item for each records, even
if the records hasn't been loaded in the cache. If a record
has not been loaded, only the record id is available, not
the other values. Thefore, this isn't possible to validate
the record values of records that have not been loaded
in the dataset cache.
opw-654013
When terms are translated in the website, their values are sent as HTML (with
text entities escaped). The function `xml_translate` is used to sanitize those
values, and sometimes crashes because of non-closed entities like `<br>`. Fix
it by using an HTML parser as a fallback.
This is a partial revert of 6c8e53a087.
Warning messages are automatically displayed if a module takes more than 1000ms to load, but this delay is a bit short if you make multiple rpc calls (sorry for all the dead kittens)
Géry Debongnie