The functions 'formatFloat' and 'formatInteger' now format
a number x like utils.human_number when a predicate 'humanReadable'
is available in options and humanReadable(x) is true.
- Change icon and design for dashboard subviews buttons, according to
the new mockup.
- Primary buttons are put into the same 'btn-group' to have better
border jointure.
! The new icon for the 'fullscreen button' requires to update
Font Awesome (currently in 4.7 and need at least the 5.0).
Task #1882571
The read_group method will ignore and display a warning when giving an
order on a non-aggregable field. Therefore, when accessing a list of
record from a list view group by some field and ordered on another one,
a warning will appear in logs (making the nightly clikall test yellow)
The solution here is to only order by current group by field and on
aggregable fields. We want to keep the user order to know the ASC/DESC
information.
Before this fix, in form view, when a datepicker was not visible (because
they were on another page or literally invisible), when the user pressed
TAB and the datepicker was positionned after the current field in the
form, it was capturing the focus during the activate phase of the
navigation_move.
This is not correct for invisible elements.
After this fix, only focusable datepickers get the focus during the
activation phase of the navigation_move.
co-author: aab-odoo (aab@odoo.com)
Menu items for measures list are now sorted by their 'string' value.
We set that string in lowercase because uppercase/lowercase influences
string comparison, so we are sure to compare always strings with the
same case.
This fix is effective for pivot view, cohord view and graph board.
Task #1882576
Purpose
=======
The 'CREATE' operation lacked the possibility to handle multiple records.
The 'context' parameter is now an array of dict that contains the context for each new record.
This is usefull when you want to create multiple records into a list in a single call.
Please note that the 'default_get' is still called once for each record in an async way.
Task #1871557
Purpose
=======
- Configure a product from a sales order as easily as in the ecommerce
The backend uses the same template as the frontend to configure a products and its options
- Display optionnal products of optionnal products in the "sale options" section
- Allow adding exlusions to some combinations of the product and/or
to some combinations of the optionnal and accessory products
Specification
=============
PHASE I
1. Improve the "Add to cart" with optional products
- When you add an option to cart, move the product to the cart & show the options of this option
- Don't open the option wizard if no option available (in case this module becomes generic,
it's better to skip this step when it's not needed)
- Display the options right under their related product in the cart
2. Do not allow to add the product as an optional product for itself
Why ?
- No functional sense
- Creates issues in the add to cart wizard
3. Exclude some attribute combinations within the product or with related options and accessory products
- Rename VARIANT PRICES button -> CONFIGURE VARIANTS
- When you click this button and select a value, open form view rather than inline edition
- Form view of variant values:
- Attribute
- Value
- HTML Color Index
- Attribute Price Extra
- Not Compatible with: o2m tab with 2 fields: Product AND Attribute Value (of this product)
[m2m tag selection]
- in any new line, autocomplete the current product by default
- Tooltip: A list of product and attribute values that you want to exclude for
this product's attribue value. Also applies on optionnal and accessory products.
4. New option to configure a product in a sales order line
- This option is only visible if the corresponding option is activated in the sales settings
- It opens a wizard to select a product template, configure related attribute values
and select optional products (based on frontend view)
- Attributes not compatible with other selected attributes should not be selectable
- Must work like in the frontend
With this commit, we limit the kanban view to 10 open groups
at the start. This is useful to prevent the web client to make
too many requests at once.
This limit is set in the constant 'OPEN_GROUP_LIMIT'.
Note:
- columns already set as folded by default aren't take into account.
- the user can still open any folded column, as usual.
Task #1878113 (1/2)
In some forms (especially invoices), there are more than one action
"add a new line" on the invoice lines one2many. When using the keyboard
to access those links, some kind of style is required to identify which
link is currently focussed, else the focussed link is not visible.
Before this commit, when we click on the 1st control in
an editable list (usually 'Add an item') then press ESCAPE,
the focus was not on the 1st control.
The intended behaviour is to have the focus on the 1st control,
so that we may navigate left/right between controls solely with
the keyboard.
With this commit, when a cancel keyboard navigation event is
triggered in an editable list, it auto-sets the focus on the
first control.
Co-authored-by: Alexandre Kühn <aku@odoo.com>
This commit fixes a few issues with the previous implementation of the
automatic addition of new lines in x2many inside forms
1. Before this commit, when there is a change of mode in a formview
`edit` -> `readonly` -> `edit`, there may be some cases that
mistakenly and automatically opens a modal.
This case occurs in a form view with a x2many field whose 1st inner
focusable element opens a modal (e.g. "Add an item").
In `edit` mode:
1. Open this modal from the x2many
2. Close the modal
3. Change mode to `readonly`
4. Change mode to `edit`
> the same modal is automatically open.
This is due to the tracking of the last activated field that persists
after a change of mode. Since the last activated field in the 1st
`edit` is the x2many, it is granted the focus at the beginning of the
2nd `edit`, which automatically opens the modal.
This commit fixes the issue by resetting the tracking of the last
activated field when there is a change of mode. As a result, at the
beginning of the 2nd `edit`, the focus should always be on the 1st
field.
2. Before this commit, if the focus was moved out of the form (to a modal
for instance) then back, the form would re-activate the last field, which
is the x2many and would re-add a new line. This behavior is not correct
and now going back from a modal to a form does not add a new line.
Co-authored-by: Alexandre Kühn <aku@odoo.com>
Before this change, when the focus was on the first field on a x2many
field, and the user pressed TAB, the line would be discarded and the
focus moved to the next field (at the level of the x2many) in the form.
This was an issue because if the first field was required, the focus
could not be moved out of the field with TAB so the user had to discard
the line manually (with ESC) before moving to the next field
This change works with 2 changes:
1. detecting if a line is dirty (has been modified by the user) and at
the end of the line, decide to either
- discard the line and move the next field, if the line is not dirty
- commit the line and add a new line, if the line is dirty
2. allow users to use TAB through required field inside x2many so they
can easilly go to the end of the line.
Task id : 1872248
The idea for this change is that there are different behaviors when using
the keyboard inside an editable list:
when the focus is at the end of a text field, it moves the focus to the
right cell when pressing right, but not when the focus is in the middle
of the field. Also, moving up from within a multiline text field was incoherent.
In order to simplify the keyboard navigation, only TAB is used to move
from field to field inside and outside a editable list.
Task id : 1872248
Before this commit, every pie chart without any data displayed
the non content helper in the middle of the screen.
This behavior is intended most of the time except for embedded
pie chart (such as in the dashboard views).
Now, an embedded pie chart without any data is rendered and displays
the error message in the middle of it.
We had to render it with nv.d3 to match the size of the other
graph in comparison mode.
Another commit in enterprise will add a test for this fix.
For the moment, embedded empty pie charts are only used on
dasboard views.
Since odoo/enterprise@e3b0d2a, the title wasn't set anymore.
This logic is now moved in the graph renderer to be able to
set a title in every graphs.
For now, we only use the title attribute for pie charts embedded
in dashboard views.
Additional tests has been added in 'web_dashboard' (enterprise).
Currently kanban columns propose an Archive / Unarchive option if the
records model has an active field. It allows to directly archive or
restore all records belonging to that column. It is currently not possible
to control whether this option is present or not as it only depends on the
active field being defined on the model.
In some specific cases we want to be able to hide this option even if the
active field exists. For example future commits will hide this option for
leads (crm.lead) as business flow goes through marking them as won or lost
instead of archiving / restoring them.
This commit adds support of a new archivable parameter when defining the
kanban view that hides the archive buttons if it is set to False. Default
value is true so that current behavior is kept as it is by default.
Doc and tests are added.
This commit is linked to task ID 1880051 and PR #26977.
Purpose is to add a width on dropdown 'box' in order to have long labels
like 'Set cover image' being squeezed against the border.
This commit is related to task ID 1884053 and closes PR #26936.
On MAC, some characters can only be typed using the ALT+Number that was
reserved for the menu access keys.
There is a system in place to collect the ALT+Number keys and force the
activation of the shortcut to make the experience better for all users
across all machines.
This fix remove this system that collects ALT+Number or other keys on MAC
Ticket number : 1887171
The change of navbar color from blue to purple in community,
also changed the the background color of the search facets were light purple
before this commit.
This commit fixes the background color of search facet to light gray,
which should look almost the same as before the change above.
This commit improves UI of charts:
- Reduce margins of svg
- Put ticks label on right of y axis
- Bigger lines (line chart only)
- ligther area color (line chart only)
- Hide y axis line
- Force charts to begin at y=0
- Hide zero tick on y axes
There is no test because these changes only concerns visual effects.
Task ID: 1877588
Before this rev., the pie_chart widget was rendered from scratch
with nv.d3 and we had duplicated code.
In comparison mode, two widgets were instancied and it was a bit
difficult to synchronize the size of these svg graphs.
nv.d3 graphs are attached when the dom is ready because it needs
to calculate the available space. UI bugs can appear if the dom
changes... .update() must be executed on the graph to avoid this
as we already do in graph renderer.
So now, the rendering of the pie_chart widget is done by the
graph renderer.
As comparaison mode is supported by the rendering, only one
widget needs to be instancied.
Task ID: 1835644
This was necessary because the rendering was always determining
which app item should have the class 'active'.
This was an issue with the 'Click Everywhere Test': at the beginning
of the script, it gets the jQuery element that matches all nodes
`a.o_app` in the app menu. When an app item is clicked, it re-renders
the whole app menu, so that older referenced nodes are detached from
the DOM. As a result, clicking on them no longer works, because it
never triggers the MouseEvent `click .o_app`.
This commit fixes the issue by rendering the whole app menu once.
When an item in the app menu is clicked, it dynamically changes
the `active` app.
The navbar in community now looks more like the navbar in enterprise.
Here is a sum-up of the changes in community:
- The navbar in community is now in blue, instead of black.
- No more app list that almost fills the whole navbar: there is
now an "Apps Menu" in the left-most side of the navbar.
- No more sidebar for the menus inside an app: those menus are
now located in the middle part of the navbar.
The navbar in community does not support mobile (< 768px width),
but it should still somewhat usable on most mobile devices.
As for the website navbar, it has been unchanged and should still
support mobile layout.
Task-ID 1878649
The datepicker lib has been updated to tempus dominus (BS4)
recently, but our code hasn't been adapted correctly to the
requirements of the new version of the lib. As a consequence,
the datepicker didn't close itself when the input was focused
out anymore.
This required a slight change in the DomainSelector widget as it
produced a crash when a focused datepicker widget is removed from
the DOM (before the datepicker is destroyed), e.g. by a call to
html() on one of its parent.
Task 1878254
Revision on https://github.com/odoo/odoo/commit/0de5c1f076d7e7d0e5361e08c810c727bd41d9e0
With the commit above, the following error was shown in the devtools
when accessing a frontend page without website that is installed:
missing module "[root.widget]"
This is caused by the fact that there is no root widget in the frontend
bundle without website installed. This may prevent executing tours
in some cases, because the tour manager needs a root widget to run.
This commit solves this issue by ensuring a root widget in the frontend
even when website is not installed, so that tour manager can run.
This rev. is similar to db9b91ff, but treats the x2many case.
Calls to the 'commitChange' function of renderers must not be done
inside a mutex, mainly since 241704536, as they could end up in a
deadlock. For x2manys, it was actually the case in practice in
Inventory > Operations > Inventory Adjustments > Create > select
'One product only' > select a product > try to edit the real
quantity in the editable list > focusout > deadlock.
The reason why the deadlock occurred in this view and not in, e.g.
sale.order, is due to the presence of the field_float_scannable
widget. Indeed, the barcode engine intercepts input events and
manually re-triggers them. As a consequence, the 'change' event is
not triggered on the field, and it does not notify the environment
of its new value by itself, until the field x2many asks it to
commit its value. Note that this might be an issue as well, as
onchanges are thus not triggered.
Task 1878254
Rev. f241441 recently added the possibiliy to define custom
controls (instead of the single 'Add a line') in editable list
views. However, it didn't take into account keyboard navigation.
Suppose that the focus is on the field preceeding the list, and
the user clicks on TAB, the code assumed that there was only one
control, and focused it. However, when there were several control,
the last one was focused (which is typically the less common one),
and there was no way to navigate to the others.
This rev. focuses the first control by default, and allows to
navigate through controls with RIGHT and LEFT. Pressing TAB still
moves out of the list, to the next field.
Note that i'm not happy with this fix, as the logic doesn't seem
to be in the right place. Indeed, the notion of controls is the
concern of the editable list, not the x2many field, so the list
should handle this logic by itself. Unfortenately, this is not that
easy to change, as for now the list doesn't even know that we are
navigating to/from its control(s), until we click on it/them.
Changing that will be for later, in master.
We also did a linting pass on the concerned code.
Task 1878254
We're not shipping the sourcemap files, and while the assets minifier
strips out the mappings they're getting hit in debug=assets which is
bot useless and problematic when running odoo-bin without a proxy for
static folders: if sourcemaps are enabled (which is apparently the
default in all browsers if devtools are opened at this point) the
browser tries to fetch the sourcemap, which does through the
SharedDataMiddleware which doesn't find them and passes the query on
to the regular Application which goes through the entire dispatch &
NotFound process.
If website is installed, that process ends up rendering website.404,
which can be pretty costly until everything is properly cached:
# initial request
"GET /web/static/lib/bootstrap/js/index.js.map HTTP/1.1" 404 - 319 0.198 0.954
# a few requests later
"GET /web/static/lib/bootstrap/js/index.js.map HTTP/1.1" 404 - 27 0.022 0.060
And the way sourcemaps are fetched (might be headers, might be the
stampede as browsers will try to fetch a dozen sourcemaps as fast as
possible) seems to make this problem much, much worse: instead of 300+
the requests take 800+ queries each, multiple seconds, and requests
get worse as time goes on (didn't investigate the exact reason for
that) *and* they apparently don't ever get cached (at least they don't
after half a dozen reloads of the client).
Mathieu Duckerts-Antoine