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)
Variable 'event' is magically defined on some browsers like chrome, but not on
firefox. Anyway, those preventDefault() were useless as they are performed
beforehand.
This filter filters requests for this year. However allocation requests do not
have date_from and date_to. For requests not having those dates the filter
takes requests whose type (holiday_status_id) is active. This was the old
Year filter, that is applied only to allocation requests now. Leave request
are still based on date_from and date_to.
Revision 1e90257e58 removed hierarchy in
hr.employee.category model. Indeed they are used and displayed like tags
and not like hierarchical categories anymore.
However the allocation by tag was still using the childof operator
to go through hierarchy. No need to do that anymore.
Product grid layout is made with a table with colspans and rowspans
alongside fixed height cells (according to rowspan values). The fixed
height for cells was required because of chrome, which cannot have
fixed height rows to work properly. However, for some reasons, fixed
height cells combined with rowspan does not work everytime on firefox.
Solution is to combine the right solution (fixed height row and let the
cells compute their height according to rowspan values) and the fixed
height cell hack for the system to work on chrome.
This commit also corrects changes made in some previous commits in
website_sale.css without going through the .sass file.
It was bound to happen: some functionnality need to be triggered depending on the current edition of Odoo. To do this, we add a property 'version' on the global odoo object.
This change is mirrored on the enterprise repo.
Christophe Matthieu