Before this the user was unable to see what value was currently
selected in the selection widget (used for selecting users and fiscal
positions). This implements support for an optional 'is_selected'
function which gets an item from 'list' as a parameter and should
return true when the item is currently selected.
This also removes the fiscal position name from the fiscal position
button because there wasn't much room on the button to fit the name
and with this feature that information is redundant.
The twitter settings view contained a link which opened an inline modal
with a tutorial. As inline modals are not supposed to be supported by
the backend (the Dialog JS class should always be used), this is removed
and replaced by a link to the online Odoo twitter documentation.
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.
When an image is added thanks to the media dialog, the URL that is used
was '/web/image/<id-of-the-attachment>'. Now the name of the image will
be added for SEO purposes ('/web/image/<id-of-the-attachment>/<name>').
Also protect URLs with quotes to allow spaces.
- 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
Use case to reproduce the bug:
- Set multi location in settings
- Set warehouse's deliery method as pick/pack/ship
- Deliver a product to customer
- Process a return from customer to output.
- Create a return from output to pack ->
Unable to reserver product.
It happens because return moves where not linked together but have
the picking that created the return as origin.
Thus action_assign does not detect the return moves and can't
guess the real quantity available.
This commit add a behavior that will create links between
return move. It can be guess from parent move(the picking's move from which
the return is created) and its move dest/orig that have already
created other return. It also correct action assign because
the group by could retourn same line with return moves.
It add a test that check returns and links between them.
When deacreasing a quantity on a PO it will decrease the quantity
of an associated move. When the move's quantity reach 0, previously the
move was unlinked and aslo the picking if all moves inside were unlinked.
However the destination move(s) still exist with the quantity that has been
removed in the original move. It can confuse the end user which have a move without
origin.
This commit cancel the move/picking instead of unlink them. Thanks to this
the end user still have the link with the original moves and can guess from where
their destinations moves come from. It also remove the filter on PO in order
to display the canceled picking.
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.
commit 0a960c08757a8ba5e1dc1dd36c17a35de8913975 introduced change about
reserved quantity that set it to 0 once the move is done.
This commit add views improvement. If the move lines are done
reserved quantity does not really matter and thus it is better
to not display it.
Modify the decorator on stock picking that change the font to red
if the quantity processed is greater than the reserved quantity.
This decorator does not trigger if the picking is in state done since
reserved quantity is always 0.
When validating a stock picking there were 2 different cases:
(1) If all qty are equal to 0 it will display a wizard asking
if the user want to set the quantity done to the reserved quantity
for all moves. If the user accept it will automatically perform the
moves after setting the quantity done.
(2) If the user set a quantity on a move, it will check if there is
a need for a back order. If yes it will display a wizard asking if
a back order is needed or not.
However the check if a back order was needed or not was never perform
in case 1. If the quantity reserved was lower than the initial demand
a back order was automatically created.
This commit add the step 2 in the procedure of step 1 (after setting the
quantity done).
The quantity reserved for move was never modified once the move
is done. It is a nonsense to have a reserved quantity for a done
move.
This commit add a constraint that ensure the quantity of
move line to be 0 if it is in state done. Also it add a write
on move_line's 'action_done' function that set the reserved quantity
to 0 for all move line processed.
It does not introduce any change on the stock move itself since the
reserved quantity is the sum of all its move lines's reserved quantity.
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
This merge mainly does 2 things:
- move frontend chatter feature from website_mail
into portal, since chatter is required for some
business model in the customer portal. This chatter
is still also responsible of displaying comments
for website object (slides, blog, ...)
- bring project customer portal into project,
and make project module depends on portal, like
it was already done for sale and account.
hr_timesheet now contains the dislaying of timesheet
on task in portal.
website_project is removed, and we do not use
website.published.mixin on project, since this
is only used to display its rating. projects are
not public object.
Joren Van Onder