So that was a fun one: mock.patch calls would regularly fail refusing
to find the addon in odoo.addon (e.g. essentially getattr(odoo.addon,
'account_budget' deep within the bowels of mock).
Turns out the answer is that our import hooks would not be used for
many imports: while in Python 2, sys.meta_path is empty and the
default finders are run after all meta_path finders fail as noted by
the documentation[0].
However when the import system was rewritten in Python 3.3[1]
meta_path was "despecialised" and the default finders were moved to
meta_path rather than be a hidden part of the import machinery[2]:
> sys.meta_path and sys.path_hooks now store all of the meta path
> finders and path entry hooks used by import. Previously the finders
> were implicit and hidden within the C code of import instead of
> being directly exposed.
The result of this change is that ``sys.meta_path.append`` means the
default finders should take priority and the custom ones should be
fallback. This is the exact opposite of what we want.
Fix issue by ``sys.meta_path.insert``-ing our finders at the start of
the path rather than appending them at the end. This should change
nothing in Python 2 but seems to fix the issue in P3.
[0]
https://docs.python.org/2/library/sys.html?highlight=meta_path#sys.meta_path
[1] https://docs.python.org/3/whatsnew/3.3.html#importlib
[2] https://docs.python.org/3/whatsnew/3.3.html#visible-changes
https://bugs.python.org/issue13936
That's a pretty sensible change, but it turns out we did have some
bits of resource which implicitly depended on the old behaviour.
In Python 2, hasattr swallows *any* exception raised during the
access. In Python 3, it only swallows AttributeError.
Accessing an attribute on an unbound threadlocal proxy raises
RuntimeError, while running test_ir_http_mimetype ``request`` is
unbound, in Python 2 ``hasattr`` would return ``False`` on an unbound
threadlocal, in Python 3 it lets ``RuntimeError`` pass through blowing
up the test.
Fix this by just checking if the threadlocal is bound by using it as a
boolean…
In Python 3 round:
* rounds half to even (banker's rounding) rather than up
* returns an int if not given a precision (or given a precision of
None)
* discards the negative sign when rounding to 0
Add a compatibility shim which implements P2 behaviour and at least
allows passing float_utils's tests.
Implementing float_round on top of Decimal was attempted but did not
work: although Decimal.quantize takes a non-integral
Decimal (e.g. ``d.quantize(D('0.001'))``) it only supports integral
powers of 10 and does not support quantizing to e.g. 0.05: while that
will not fail it will just use the exponent for quantization and 0.05
is thus equivalent to 0.01, which is not what we want if e.g. need to
round a value to 5 cents.
This is hinted at but maybe not clearly spelled out by the official
documentation:
> Return a value equal to the first operand after rounding
> and **having the exponent of** the second operand.
Also convert a bunch of hand-rolled currency rounding to just using
the round() method on res.currency.
This commit adds a 'Create and Edit' button in the footer of the
dialog opened when creating a record from the Kanban of several
models. Clicking on this button creates the record and directly
opens it in a more detailled form view in edit mode.
This commit adds an 'Edit' button to the record quick create in
grouped Kanban views. When this button is clicked, a name_create
RPC is performed and the created record is directly opened in a
form view in edit mode.
When displaying only invoices, a "Credit notes" filter is useless (and
vice-versa). Filters will be called "Not draft"
When displaying both, keep filters for Invoices and Credit Notes.
Before this the POS would load product.product records with
pricelist_id defined on the pos.config in context. These unit prices
were then used everywhere in the POS as-is. The POS contained no
pricelist logic at all.
This implements the full pricelist logic in the POS and provides a way
for users to choose what pricelist to apply per order. This
implementation closely follows the behavior defined in the product and
sale modules.
This includes unit tests for the get_price function and acceptance
tests. The unit tests are done in PhantomJS and ensure that get_price
returns the same as the backend returns when reading the 'price' field
on product.product.
Prices of products are displayed according to the selected
pricelist. To accomodate this the product_cache DomCache of the
ProductListWidget is now done per pricelist.
Additionally, this feature should speed up the loading of
product.product records. Now only stored product.product fields are
loaded. Before the non-stored computed 'price' field had to be loaded
for every product.product record.
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").
Odoo Translation Bot