Field widgets now have a key 'context' that let them
extend the context of the dataPoint (e.g. list).
In particular, widgets on binary fields enforce the contextual
item {bin_size: True}, so that the server gives the size of the
binary field as its value, instead of its content.
This change on binary fields reduces network load when accessing
a view with binary fields.
Revert partially 255e8ca3d9
Removed widget 'download_link', as it was a sub-version of widget 'binary':
it did the exact same thing (representation of binary fields by means of a download link)
in a much better-looking way (download icon + filename as text of the download link,
instead of just a download link with text "Download").
Also, the values of binary fields might be already a human-readable binsize (e.g. 2.52 MBs),
instead of its plain textual string representation in base64:
The contextual parameter 'bin_size', when set to true, does not download the data of binary fields.
As a consequence, the server provides the sizes of the binary, instead of their value.
After sepration of CRM and Sales, The xml_id of sales settings action
changed. This patch update old links in web_planner to the new settings.
opw-804426
For kanban views with attribute 'on_create="quick_create' set on
their root node, clicking on 'Create' in the control panel should
open the quick create widget in the first column if the view is
grouped and if there is at least one column displayed.
It was working as expected, except when there were no record yet.
This was because the kanban controller used the 'state.count'
attribute of the state (which indicates the total number of records
in the group), whereas it should have used 'state.data.length'
(which is the number of columns).
Before this rev., when quick creating a record in a grouped kanban
view, the quick create widget wasn't automatically re-opened, which
didn't allow the user to quickly create several records in a row
(without clicking each time on the '+').
This desired behavior had been broken by rev. 1d34e26, which aimed
to properly reload the kanban column when a record was created
(e.g. column counter, progress bar...).
`_run_move` creates the move, calls `_assign_picking` and then confirms it. The
result is that a draft move is added to a picking and then its state is changed to
confirmed. As the state of the picking is computed across its moves and a manual
call to `message_track` is done when any of its move changes its state, there was
a lot of tracking messages in the picking chatter, especially when you confirm a sale
order (a lot of calls to _run_move).
The thing is that this is unnecessary as stock.move’s `_action_confirm` will call
`_assign_picking` later on AND after having changed its state to “confirmed”. Now
a confirmed move is added to a confirmed picking and no message are posted. This
improves considerably the validation of a massive SO.
When we have a form view with a one2many with an onchange, and with
lines which contains a x2many, and more lines that the limit (so more
than one page), and the read is not in the same order as what is
displayed because we have a widget=handle, then we might have a problem
when we delete one of the lines, if the onchanges tries to change the
x2many.
This is due to the fact that the order of the basicmodel datapoint is
not preserved by the various operations going around. I think that we
may still have a few other issues of this type, but it is actually quite
difficult to establish.
In any case, this situation is now properly handled.
opw 804530
The backend assets includes a list of the installed modules with:
```
odoo._modules = <t t-raw="get_modules_order()"/>;
```
Because of the randomization of Python 3.5 in the dict keys,
the order of the installed modules could change from time to
time, therefore making the assets being regenerated unnecessarily
This revision is a bit linked to the below one:
f3bb9ae679
In addition to have the dict keys always in the same
order, it's important for the values to always be
the same, and it was not the case for this list
which was in the content of the backend assets,
in various order.
opw-804747
`sale_stock.tour` requires `sale.tour` which is defined in
`sale_management`.
Aside from the test failing, this is more logical to add the 'Sales'
menu once the set-up is past a simple 'eCommerce' configuration. Note
that it was intended in the original commit 5dfd342d08, but was
later changed back to avoid issues.
We need to depend both on `sale` and `sale_management` explicitly, to
make sure installing `sale` and `stock` separately will also install
`sale_stock`.
opw-804621
Before this commit, an user could only use the coupon form if he didn't perform
any ajax request (eg: change quantity, already sent a code..).
Since the cart html would be reinjected with theses ajax requests, the click
event would not work afterward until the page got fully reload.
Now, we changed the jquery click binding to work with dynamically injected DOM
Assuming that `field.cache_key(record)` is independent from `record.id`,
compute the cache key once for all records, and avoid using `browse` on all
record ids. This makes `get_records` about 20 times faster.
This has a good performance impact on `field.modified_draft()`, which is used
during onchanges for invalidating fields.
Before this commit:
1. If the website's homepage is unpublished and a public user naviguate on it,
it will log an access read error in the server. The user won't see the error
though.
2. If the user can't access '/', we serve the first menu's page instead.
This first menu's page can be an unpublished page, resulting in a 403, which is
not convenient.
3. Menus are sorted by sequence, then the ORM sort them by write_date.
Menu with same sequence will be sorted differently every time you edit one of
them. (This issue get hidden/solved if user edit and save the menus with
"Edit Menu" since it will recompute every sequence.)
- Create 3 pages 'A', 'B', 'C', with 'Add page in menu' enabled
- Menu is now 'A B C'
- Edit website.page B (in property dialog), it will write on the page's menu
aswell
- Menu is now 'A C B'
Now:
1. We prevent this error by ensuring the page is published and so can be read
by anyone before accessing its properties.
2. We serve the first menu's page that is published
3. We sort menu by id after sequence to keep original order
This closes#21259
Before this commit, if there was a menu entry linked to an unpublished
website.page, the menu would be shown. For restricted users, they would land on
a 403 forbidden.
Now, we dont show website.page's menu if user can't access it.
This closes#21328
Before this commit, if a website.menu had a URL set to null, it would throw an
error when displaying that menu.
It is normally not possible to do so in v11 but after a migration, menus can be
empty. (eg: Using an empty menu to display a divider in a dropdown menu)
Now we return an empty url instead of an error
An activity is always created with sudo, so it's useless to set the
image and the name of the "Administrator" all the time.
Now the image and the title of the assigned person is displayed.
opw:802759
before this commit, the selection on res.company was by default hiding the country prefix. THe option was not available on res.company view.
We fix the default behaviour and add the option in the res.company view in debug mode.
Should be from hr.employee
At a8326cc6 source model inconsistence was introduced but the bug was revealed
only after 55549f1e where it kept the wrong one
Fixes#20203
PS: this action should be removed in master in favor of hr_org_chart module
Revert 6cb12273e2 which reverted
08d48b0fff.
Issue was the support for sub-parameters (aka @param {type} foo.bar)
where the "parent" parameter was not formal (only present in a
function's docstring, but not in the function's parameters list),
subtype creation would fail to find a root parameter to attach the
sub-parameter to.
This has not actually been fixed, but for the specific case where the
formal parameters list is *completely empty* we fall back on a list of
the docstring's parameters, which works well enough for this case.
Steps to reproduce the bug:
- Create a routing with a Product Location of type view
- Create a MO with this routing
- Click on "Plan" without clicking on "Check for Availability"
- Complete the work orders
- Go back to the MO and try to put it in state "Done"
Bug:
Impossible to set the MO on state "Done". By clicking on "Mark as Done",
it returns:
You cannot take products from or deliver products to a location of type "view"
opw:803580
Current behaviour when duplicating a record:
apply copy override in the user language (e.g. "%s (copy)")
copy the previous term in all the other languages (including)
So if product was named:
cheeses (en)
kaas (nl)
fromage (fr)
Duplicating the product, while in French, will result into:
cheeses (en)
kaas (nl)
fromage (copie) (fr)
This is a problem if there is a unicity constrain on the field, it will be
raised (there is already a product named 'cheese')
After this PR:
Duplicating the product, while in French, will result into:
fromage (copie) (en)
kaas (nl)
fromage (copie) (fr)
This applies **only** if there is an override of copy
This is detected by comparing the old and new value for the user language
Fixes#7010Closes#22052
In march 2017 saas-15 on activity message, the create_uid was displayed
with 26940f8d.
In november 2017 saas-14 an activity was always created sudo() with the
change 53ad585bf.
Thus in saas-15 we always have "planned by Administrator for {user}"
not making sense.
opw-804409
closes#22113
1. Create a new user with all the permissions as manager (or at least
Accounting) except Inventory
2. Login and then go to Invoicing --> Settings
3. Do a minor change, save
An access error occurs.
Since the settings of all modules are smartly loaded in v11, it now
implies that a user must have extra manager access rights to be allowed
to save them. We could have kept separate actions for each setting page,
but we would have missed the fun of access errors.
Anyway, security-wise this is not an issue to force the manager groups
since a user with 'Settings' access rights can change his own rights.
It's just very annoying. Or fun.
Complement of aa65a46fc5Fixes#21766
opw-801210
When you create a down payment invoice from an SO, the product that is used in the line is 'Down Payment'.
The description of this product, which is visible for the customer, was not translated to the language
of the customer in the SO and in the invoice. It was translated to the language of the user logged.
This fix is made to keep the same behavior for the description of an SO line and for the description
of the invoice line.
opw:803977
- Steps to reproduce the bug:
Go to events ->Duplicate an existing published event
Try to publish that new event
- Bug:
You get redirected to the previous event webpage, which is already published.
Unable to publish the event from that page.
The url used to access the event is computed the function _compute_website_url which
a slugify of the display_name of the event.
opw:804118
- Define a Component A tracked by lot.
- Define a Final Product B tracked by lot.
- Create a BOM, e.g. 5 units of A to produce B.
- Get some quantity of A in a sub-location, e.g. 'WH/Stock/Shelf 1'.
- Create a MO for 1 unit of B.
- When clicking on 'Produce', record 6 units consumed instead of 5.
- Post the inventory
5 units of A is removed from 'WH/Stock/Shelf 1' and 1 unit of A is
removed from 'WH/Stock'. The latter might create a negative quant if no
stock is available in 'WH/Stock'.
When the extra move line is created, it is created using the data of the
stock move (in `_generate_consumed_move_line`). When posting the
inventory, the quants selection is made strictly in the location set (in
`_update_available_quantity`), which might cause the mentioned negative
quant.
The solution is to select a sub-location where the product can be found.
This gives a higher chance to avoid negative quants afterwards. Note
that if we wanted to avoid negative quants, we could make a reservation
process on the move, and potentially create several stock move lines.
This is beyond the scope of the integration of MRP with sub-locations.
opw-803969
Code to thumbnail payment icon image had an error for python3 because
from RPC the image would be a text string instead of an expected
bytestring.
This change accepts both and made another small fix in the view since
image_medium doesn't exist (and image is already thumbnailed).
A third fix was that removing an image caused an error.
opw-803722
closes#22088
Odoo Translation Bot