Without this patch, all Qweb cache is shared among all available websites.
This turns impossible in practice to actually create multiple websites with
different look.
This closesodoo/odoo#18462
- When you move an all day event to a scheduled event,
the default duration should be 2 hours instead of 1 hour.
- Before this fix, it was not possible to drop an event
to an all day event
- In week mode, an all day event was displayed over two days.
When refunding an invoice with the option: "Cancel: create refund and reconcile",
it raised a warning: "You are trying to reconcile some entries that are already reconciled!"
because in some cases the refund is linked to several entries which match the same
account of the invoice. So it tried to reconcile several times the same entries.
opw:765673
Do not remove fields from models except for custom fields. Removing a base
field from a model screws up the model cache: that field may be required to
speed up the setup of the model in another registry.
In general (e.g. read, search_read), values for many2one fields are pairs
[id, display_name]. The default_get is an exception, it only returns the id,
so we need to manually perform a name_get afterwards. In the case of
list views, those name_get RPCs are batched.
Before this rev., the code in charge of it didn't handle the case where the
many2one value was false, so it crashed when it happened.
This rev. deals with this use case and a test case has been added.
When starting the HTML editor, the first view that is shown is supposed
to be the main one of the page by default. This was not the case for
custom pages as the 'xml_id' of the page was considered instead of its
'key' value.
- Create a product with attachment, and name the attachment 'テスト'
- Purchase the product, make a payment, validate and pay the invoice
- Go to My Orders under My Account, open the order, and try to download
the file 'テスト'.
An error 500 is raised due to a UnicodeEncodeError.
```
File "/home/nim/src/odoo/addons/website_sale_digital/controllers/main.py", line 104, in download_attachment
return http.send_file(data, filename=attachment['name'], as_attachment=True)
File "/home/nim/src/odoo/odoo/http.py", line 1595, in send_file
headers.add('Content-Disposition', 'attachment', filename=filename)
File "/usr/lib/python2.7/dist-packages/werkzeug/datastructures.py", line 1093, in add
_value = _options_header_vkw(_value, kw)
File "/usr/lib/python2.7/dist-packages/werkzeug/datastructures.py", line 830, in _options_header_vkw
for k, v in kw.items()))
File "/usr/lib/python2.7/dist-packages/werkzeug/http.py", line 212, in dump_options_header
segments.append('%s=%s' % (key, quote_header_value(value)))
File "/usr/lib/python2.7/dist-packages/werkzeug/http.py", line 165, in quote_header_value
value = str(value)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128)
```
opw-766568
In case of foreign language, using unicode characters, the error message may be
badly formated.
e.g.
Unknown error during import: <class 'odoo.exceptions.AccessError'>: เฉพาะผู้ดูแลร..
insted of
Unknown error during import: <class 'odoo.exceptions.AccessError'>: (u'\u0e40\u0e09\u0e1e\u0e32\u0e30\u0e1c\u0e39
opw-766580
New saas-16 web views have a more consistent handling of `readonly`
attributes and do not save read-only fields inside x2m. In the previous
implementation this was an exception to the rule (even if rather
inconsistent/unexpected).
A new attribute `force_save` was introduced to workaround the default
behavior when considered necessary.
The portal wizard is affected by the change, as the partner_id field of
the lines is readonly but required. It could be avoided by filling the
wizard lines before opening it, instead of relying on default values and
onchanges. However this would likely require extra boilerplate code and
an extra server action. Dropping the readonly flag would work too, but
would look weird.
Using the new `force_save` flag is a simpler alternative.
See also rev. 3b3f6f04af
When forwarding a list of leads to a partner, the lead_id was not send.
As the field `lead_id` is readonly, its value wasn't sent by the client
on save click.
This behaviour of not sending readonly fields in x2many has been correctly
implemented with the new views but some views (like this one) was basing
their behaviour on this breach.
See rev. odoo@3b3f6f0 for more details.
fix-feedback-saas16
Before this rev., the events in Calendar views (month mode) weren't
correctly displayed: the last day of the event wasn't displayed as
being part of the event. For instance, in leaves, a leave of 3 days
from the 16th of Augustus until the 18th was only displayed over
the 16th and the 17th.
Moreover, when an event was created from a Calendar view with
option all_day=False, the default start and end dates weren't
correctly computed according to the user timezone, which could lead
to the creation of multiple days event whereas the user clicked on
a specific day. For instance, with timezone GMT+2, when clicking on
the 18th of Augustus in the Leave Calendar view (month mode), it
opened a dialog for the creation of a 2-day leave from the 18th to
the 19th.
This rev. fixes those two issues.
With the new views, we stopped using the browser timezone to
display the dates in Odoo, and we used the timezone defined on
the User profile instead. When loading the webclient, the
timezone offset was put into the session and used to display all
dates. This wasn't a good idea.
The given offset was computed for the current time, meaning that
it may be incorrect for specific dates (e.g. with the daylight
saving, the UTC offset of today is not the same as 6 months ago).
Moreover (but less likely), as the offset was stored in the
session, it wasn't recalculated afterwards. So if the offset
actually changed during the session (e.g. from or to daylight
saving time), the displayed dates were incorrect until the user
reloaded the page.
With this rev., we don't retrieve the offset from the server
anymore and we use the browser timezone again (like before the new
views). However, we keep the computation of the offset (on the fly)
in the session, so that it can be mocked in the test environment.
Before this rev., all date fields values were off by one day as
soon as the user timezone was negative.
With the new views, all dates manipulated by the JS are moment
instances in UTC, and when being displayed, they are correctly
formatted in the user locale by applying the timezone offset.
However, this should obviously not be done for date fields as
when no time is specified when creating a moment instance, it
defaults to 00:00:00, so applying a negative offset always leads
to the day before.
Remark:
It happens that datetime fields are displayed as a date (e.g.
purchase order line form view). In that case, the offset is
applied on the displayed date.
In the curent behaviour, the users of the challenge are ordered
regardless of the goal definition (higher wins or lower wins).
This impacts the report email with the podium of users and always puts higher on top.
This fix changes the ordering depending on the goal definition type.
As its name indicates, the SelectCreateDialog is meant to select and create,
not edit.
If the view is editable, clicking on an element will edit it instead of
selecting it. For this reason, the view is set in `readonly` even if the view
arch uses the attribute `editable`.
Before this rev., you couldn't select a "Close Reason" when closing a
subscription (in "Search More").
Timesheet created using the UI are supposed to all have an employee defined.
However, this field is not required and it is possible to have timesheet without
a user defined.
Feedback ged from saas-16 migration
As of saas-16 and the new web client views, the "display value" for a
record's ID is now formatted with thousand separators.
This breaks a few kanban views where the ID was inserted into a
dynamic URL. Using `raw_value` is correct too and fixes the problem.
Note: This might affect other kanban views using integer field values,
but a quick search did not yield anything. Many2One fields already had
different "display values", so `raw_value` is already used when needed.
Other integer fields, such as computed counts and sums are often
displayed but not inserted into URLs or technical values where
the problem would occur.
The inventory adjustment form is not suitable for large inventories.
First, a list view embedded in a form view is not convenient since it
doesn't provide any search capabilities. The user has to rely on the
search feature of the browser, which has restricted features in
comparison to the Odoo search field.
Then, the existing onchange mechanism coupled with computed fields
triggers heavy computations impacting all lines each time a single
line is modified. This leads to a hanging page for every inventory line
modification, which causes a non-negligeable loss of time.
This commit introduces a new tree view for inventory lines, accessible
thanks to a stat button on the inventory page. This button is available
in debug mode, if the inventory is in state 'Confirmed'. The tree view
contains the same fields than the tree view embedded in the form view,
without the flaws of the latter.
opw-760614
Fixes commit https://github.com/odoo/odoo/commit/02c748be59ac8abc44c945218587e7b8a8e06a28:
Blog content field should not have been marked for any sanitization at
all as it is a field whose content is editable only by users through the
website editor. Any content should be authorized there. In particular,
some snippets contain form elements (like <input/> tags) which are
never accepted during sanitization.
opw-752458
To reproduce:
- Buy a product costing 0.01
- Validate the cart, pay with Stripe
- Enter the credit card info, validate
Stripe cannot process the transaction (minimum charge is not met), but
the user is not warned about it. The Stripe pop-up is closed and the
error is recorded in the console silently.
opw-765775
Purpose
=======
Currently an employee can
- Create mail.followers
- Write on mail.follower if it is related to his own partner
When creating a record with followers (example: An expense sheet), the followers are created but the function fields are recomputed and stored on the table (if store=True).
In that particular case (Create: ok, Write: ko), this recomputation will trigger a write and then an access right error with a transaction rollback.
Specification
=============
Adding the `compute_sudo=True` attribute on the `res_model` field, the recomputation will be allowed for users at the record creation.
This fix doesn't imply to update the modules.
Currently, the 'environment group by', if previously empty, is set to a
view-specific default value when filtering in a Kanban view. This then
causes an unexpected 'group by' when switching away from a Kanban view,
since the expected behaviour is to only take a Kanban 'group by' into
account if it was explicitely set by the user.
This is caused by the fact that the 'search' event triggers a view
reload which takes the environment as parameter, while the Kanban view
reload overrides the group by (arrays are passed by reference).
Both result in an undesired modification of the enviroment.
We fix this bug by giving a shallow copy of the environment as parameter
when triggering the view reload.
Since rev. https://github.com/odoo/odoo/commit/ebd17217c4e7e9ff06d97028de64fb2fc44d6266
the attribute `_editionViewType` has been introduced to use the modifiers from the correct
one2many view type.
This attribute wasn't correctly populated if multiple one2manys were imbricated. The
first view type (form in the test case) was set for the second one2many even though
the view type was list. This was due to the `visitChildren` function use that browses
through all levels (and not only the first one).
To reproduce the bug before this rev. you could try to create a new survey, add a
question (one2many) then select multiple choice and add an answer (one2many editable).
If a google application has no client_id or client_secret during the update
process (e.g. was configured but the API keys have been removed and the tokens
have expired), the method will crash.
Instead of continuously try and produce a traceback, return a proper error message
Closes#18613Closes#18614
In grouped Kanban views, the list of res_ids of the displayed
records may change for several reasons:
1) 'Load more' is clicked for a column
2) a record is moved from a column to another
3) a record is moved inside a column (resequence)
4) a column is moved
5) a column is (un)archived
6) a column is (un)folded
7) a record is created/destroyed directly from the Kanban.
When this happens, the environment must be notified of the new
list of res_ids (the order matters). Before this rev., this wasn't
the case. As a consequence, when a record was opened in a Form view
after one of the 5 operations above, the pager could display
unexpected values.
Note that before the new views, cases 2, 3 and 4 weren't handled,
and case 7 already worked before this commit.
Christophe Simonis