Before this commit, when the user unfold a node in hierarchy view,
he has to scroll to be able to see the child nodes added.
This commit adds an auto-scroll when a new row is added to directly
show the child nodes added on the view when the user unfolds a node
in the hirarchy view.
task-3376776
This commit adds a new menu called `Org Chart` in Emnployee menu
to directly have the Org chart view as first view when the user
clicks on that button.
task-3376776
This commit allows the user to drag and drop a record (hierarchy
node) into another one to set the one hovered as the manager of the
one dragged. It also allows to drag a record into a row to define
the manager of the row as the manager of the record dragged.
This commit also adds an new attribute on `hierarchy` tag to use
when we define that view for a certain model to enable the drag and
drop feature.
task-3376776
Before this commit, the icon displayed inside the Unfold button with
the number of child nodes is the default one. In the employee hierarchy
view, since the child nodes are obviously employees, the icon could
be the one displayed users (`fa-users`).
This commit adds a new attribute called `icon` on `hierarchy` tag
to be able to define another icon displayed on that button. By
doing that, the icon displayed inside employee hierarchy view can
changed to have the one expected and more relevant.
task-3376776
Before this commit, the user can unfold a node in hierarchy view but
before clicking on it he cannot know how many child nodes there are.
This commit adds the number of child nodes in the Unfold button with
the default icon.
task-3376776
Before this commit, the icon of the hierarchy view should be rotate
of 90 deg to have an appropriate icon for the view. The problem is
since the icon class is added on button classes, the button will
also be rotated with the icon instead of just the icon.
This commit defines a `i` tag inside the `button` element to select
the view to be able to apply css rotation only on the icon instead
of the whole button.
task-3376776
This commit extends the kanban compiler for the hirarchy view. Some
changes has been done in the kanban compiler to be able to reuse the
existing code.
task-3376776
This commit adds a new view called hierarchy view, that view allows
the user to visualize a hierarchy in a model. For instance, that view
could be used for `hr.employee` to easily visualize the hierarchy
inside the company (the manager and his employees) as an Organization
Chart.
That commit introduces a new method for the hierarchy view, called
`hierarchy_read`, that method will be when the view will be loaded
to get the initial data to display.
Some details for the definition of that new view:
------------------------------------------------
Some attributes can be defined on the `hierarchy` tag:
- `parent_field` (default='parent_id') contains the parent field name
to use to find the parent record of the current to build the hierarchy.
- `child_field` (optional attribute) contains the child field name
to use to find the child records (it is in fact the one2many field).
If that field is defined then some queries can be avoided since we
directly fetch the children when a read/search_read is done.
Inside the `hierarchy` tag, the fields to read can be added and then
a template as to be defined as we do when we define the kanban view.
The template to create is called `hierarchy-box` and that template
will be used to display the card inside a node in the hierarchy view.
task-3376776
Before this commit, the hr presence status icon is hardcoded in
each view in which the icon is needed.
This commit creates a widget for that icon to be able to use that
widget in the views in which the icon is needed to avoid duplicating
the code.
task-3376776
Before this commit, when search menu is not displayed in the
search view, then the border right is missing.
This commit removes `border-end-0` class added in the search view
to always have a border. Even with the search menu, it does not
seem to have an extra border.
task-3376776
Before this commit, `child_of` operator is managed in the mockServer
but not the `parent_of` one.
This commit manages `parent_of` operator in mockServer to be able
to find the record when the domain used contains that operator
task-3376776
This commit introduces 3 new inner snippets: button, image and video.
What sets these snippets apart is that, once dropped onto the page, they
transform into basic HTML code, just like if they were created using the
editor (no data-snippet etc).
task-3248881
closesodoo/odoo#126717
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: bvr-odoo <bvr@odoo.com>
In commit [1], the Banner snippet has been redesigned in order to be
in grid mode by default, to highlight some cool features of the editor.
However, some grid classes and attributes are missing or not well set:
- the first column has a `g-height-4` class despite having 8 rows: this
causes the vertical resize to not work correctly.
- the row does not have the `data-row-count` attribute, which is needed
to display the background grid correctly.
This commit fixes this by replacing the class by `g-height-8` and adding
the `data-row-count` attribute, which is set to 11 rows.
[1]: https://github.com/odoo/odoo/commit/3cbdf754ff8fac8a77887c4307b658cb86b0be1d
task-3369695
closesodoo/odoo#136683
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, toggling the "Text Cover" snippet to grid mode did
not produce a good-looking result: the column containing the background
image loses all its padding and therefore appears smaller and shifted
compared to the normal mode.
This commit adds a background color to the image column. Indeed, with a
background color, and more precisely thanks to the `o_cc` class, the
padding is taken into account when computing the grid items size, making
them look similar to how they were in normal mode.
task-3369695
Part-of: odoo/odoo#136683
The `display: grid` property allows to modify the spacing (or gaps)
between the rows and columns of the grid with the `row-gap` and `column-
gap` CSS properties. When the grid mode was added with [1], these
properties were deliberately ignored and the gaps were forced to 0px.
This commit adds the "Spacing (Y, X)" option that allows to modify these
grid gaps. A grid preview is also added when using this option, in order
to visualize what is being changed in the grid.
[1]: https://github.com/odoo/odoo/commit/cc406afcea7bf5846233a9f97a4a8ac5f618f3ec
task-3369695
Part-of: odoo/odoo#136683
In the grid mode code, the code managing the transformation of a grid
item into a normal column (when it is dropped or when we toggle the
normal mode) is repeated at several places.
This commit fixes that by creating a function doing this conversion
instead.
task-3369695
Part-of: odoo/odoo#136683
Before this commit, when using a `we-input`, there was no way to easily
specify the min and max values that could be entered in the input, which
could be useful when too low/high values could break some behaviors, for
example.
This commit adds the support for the `data-min` and `data-max` data-
attributes in `InputUserValueWidget`. More precisely, when these
attributes are added on a `we-input`, if the user writes a value smaller
than the `data-min` or bigger than the `data-max`, the value snaps to
these bounds. When using the arrows, the value cannot be decreased/
increased beyond them either.
task-3369695
Part-of: odoo/odoo#136683
Co-authored-by: qsm-odoo <qsm@odoo.com>
When cloning a snippet, if it had some previews displayed, the previews
may be cloned with it. This is not a good behavior because the clone
is a new snippet so it should not have all the preview classes that were
added when editing. Moreover, these previews could also cause bugs.
To solve this, an idea could be to call the `cleanForSave` function of
all its options before cloning the snippet. But the problem is that in
some options, the `cleanForSave` function does more than simply clean
the UI (as it was originally supposed to) and so it cannot be used for
that purpose only.
As a solution, this commit adds a new function called `cleanUI` whose
exclusive purpose will be to clean the snippet UI. In the future, it
will replace the `cleanForSave` function.
task-3369695
Part-of: odoo/odoo#136683
Co-authored-by: qsm-odoo <qsm@odoo.com>
Similar to d2edee2f6a6
Before this commit, web crawlers may endlessly index pages with tags,
the number of combinations were very large very quickly and could lead
to thousands of requests
opw-3525473
closesodoo/odoo#138718
X-original-commit: 953ac4bde2258d31c2d2f3f6233fb00c802b6e7f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Followup of odoo/odoo@eb7a32c31c, on large database with lot of
account.move computation still take certain amount of time and database
resources.
This commit limit the computation of `days_sales_outstanding` only
to the commercial partners that we need.
Note: the field is only shown in the Partner form view, so most of
the time we were only computing it for a single record
| Before | After |
|--------|-------|
| 900ms | 20ms |
opw-3530408
closesodoo/odoo#138703
X-original-commit: f968ea2898d7ce314fd575da5446b0dd9d711524
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
This commit modifies the "New Page" dialog so that it displays a list
of page templates to pick from in addition to the possibility to create
a blank page.
task-3381714
Part-of: odoo/odoo#126719
Co-authored-by: stefanorigano (SRI) <sri@odoo.com>
This commit adapts the configurator so that the pages it generates are
composed of the primary templates generated from the manifest by the
previous commit.
task-3381714
Part-of: odoo/odoo#126719
This commit is a preparation for the new page from template feature.
In order to make it possible for new page templates to be customizable
at several levels from themes, it was decided to create several layers
of primary templates.
Those templates are build from the descriptions found in manifest files
under the new `new_page_templates` key.
The same principle is also applied for configurator pages (described in
manifest files under the `snippet_lists` key) because we noticed that
some of the changes that were made in themes for some blocks were not
supposed to impact the "drag'n'drop" version of the block, but only
the version used inside the pages generated by the configurator. (E.g.
connecting shapes between blocks)
The manifest entries now have the following structure:
```py
'snippet_lists': {
'somepagename': ['s_block_name', ...],
},
'new_template_pages': {
'somecategoryname': {
'sometemplatename': ['s_block_name', ...],
},
},
```
This commit finds those entries in the manifests and creates the
following primary templates:
- `s_block_name`: already exists, this is the block that is drag and
dropped using the website builder
- `configurator_s_block_name`: specialization of `s_block_name` used in
all pages generated by the configurator
- `configurator_somepagename_s_block_name`: specialization of
`configurator_s_block_name` for that specific page
- `new_page_template_s_block_name`: specialization of `s_block_name`
used in all new page templates
- `new_page_template_somecategoryname_s_block_name`: specialization of
`new_page_template_s_block_name` used in new page templates of that
specific category
- `new_page_template_somecategoryname_sometemplatename_s_block_name`:
specialization of `new_page_template_somecategoryname_s_block_name` for
that specific template
For the template pages defined in `website` it also creates primary
templates that assemble `t-snippet-call`s of the most specific block
templates. Those templates are named
`new_page_template_sections_somecategoryname_sometemplatename`.
task-3381714
Part-of: odoo/odoo#126719
Before this commit, websocket tests were sometimes failing with the
`no result to fetch` error. This is due to a race between the
`subscribe` event being received which itself leads to dispatching bus
notifications interferring with the rest of the test (the connection
is shared).
In order to solve this issue, the `WebsocketCase` now exposes a
`subscribe` method that waits for this dispatching to be done in order
to ensure it will not interfere with the rest of the test.
Some tests were also failing because the subscription was done with 0
as the last notification id. This is an issue since this could lead to
notifications being sent while they are not expected.
In order to solve this issue, `last_notification_id` is now correctly
passed when subscribing to channel notifications.
fixes runbot-24226
closesodoo/odoo#138649
X-original-commit: 3256885fd08d33a67d7165fa33d373fd039ef7af
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
The issue with the t-cache (discribeds with a test in previous commit)
is that the key/value can be anything. It can be based on other t-cache
(assets in the example) but could be anything else.
The proposed solution will clear the t-cache when ANY other cache is
cleared. This is similar to the behaviour when the t-cache was
introduced (single ormcache)
Also sligly improve logging to precise what was cleared
closesodoo/odoo#138647
X-original-commit: aa69fa9f8efed0da45c601e5d57ce252446e376f
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The issue that can happen is a t-cache covering a t-call-asset.
The asset_cache is invalidated but not the t-cache, meaning that the url
pointing to the asset will lead to a 404 once another request, without
t-cache, will regenerate the asset.
X-original-commit: fffc198914b8c885905e9dddd72b6490fcc4c120
Part-of: odoo/odoo#138647
Since commit [1], the 'jquery.ba-bbq' library has been removed. Now,
when you drop the Facebook snippet into a page, there is a traceback.
This is because we were still using the 'querystring()' function from
'jquery.ba-bbq' to combine the parameters of the Facebook iframe's URL
with its URL.
[1]: https://github.com/odoo/odoo/commit/507c36883675a45a15485ce5c73aa4557ba23639
task-3543529
closesodoo/odoo#138592
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
**ISSUE**
- Given a combo product with 2 combo_ids (pos.combo).
- Combo A
- A1, A2
- Combo B
- B1, B2
- When adding this combo product, it's possible that the user selects the
combination A1 & B1.
- And in another order, A2 & B1.
- ISSUE: Between those two orders, prices of first line (component A) will be
different. What we want is that the price of line corresponding to a component
(pos.combo.line) is consistent between orders.
**SOLUTION**
This can be achieved by establishing a constant in each pos.combo.line. We
choose the minimum lst_price of the components as this constant which we call as
`base_price` field.
The calculation will be practically the same as before, except unit price is now
based on the `base_price` field:
- Compute the original price - which will be based on the `base_price`.
- Recall: `base_price` is the minimum price among the `combo_line_ids` of a
pos.combo.
- We then divide the original price to the target price (which is the price of
the combo product) which we'll call the "prorateFactor".
- The price of the components are computed by multiplying the "prorateFactor" to
the `base_price`.
**Rounding error:** Both the original procedure and the new strategy introduced
in this PR suffers from rounding error. To prevent the rounding error, we
compute the error and distribute it to the last line of the combo.
**Combo (Extra) Price:** The `pos.combo.line.combo_price` is added on top of the
prorated price.
closesodoo/odoo#138352
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
**Steps to reproduce:**
- Install pos and pos_restaurant.
- Make sure preparation display tracks a pos.category, e.g. 'Food'.
- Open restaurant with the 'Food' category in mobile mode.
- ISSUE: The product reminder just above the 2 switch pane buttons is not shown.
**FIX:** The product reminder is not shown because the "change" name used in the
calculation for comparison has a trailing space. We just have to make sure that
the trailing space is not there.
Part-of: odoo/odoo#138352
It's possible that a product is loaded but its pos.category is not, e.g. when
loading a menu product (product with detailed_type='combo'), the components will
also be loaded.
In this case, the product's pos.category will be null and the product won't be
visible even when in the root category. This commit makes sure that if a
product's pos.category is not loaded, the product will be visible in the root
category.
Part-of: odoo/odoo#138352
Because some payment methods get deprecated or are
used very little, an active field comes in handy.
closesodoo/odoo#137914
Related: odoo/upgrade#5253
Signed-off-by: William André (wan) <wan@odoo.com>
The field was foreseen in advance in the community module,
but the final implementation of the electronic invoicing
did not need it.
Part-of: odoo/odoo#137914
before this commit, on printing product labels there
is no option to select the price list, always the
printed price is the default product price
after this commit, in the label printing wizard
the price list field is introduced and user can
select the price list before printing the labels
closesodoo/odoo#137190
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Better API as the arrow was not displayed when the fixedPosition
prop was true, which is as we were mixing apples and pears.
And as for the animation prop, it permits to remove the hacky
"o-fast-popover" class usages.
closesodoo/odoo#135188
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
**Before this commit**
The TourPointer component make use of a deprecated
function (reposition) in order to position itself.
**After this commit**
The TourPointer now make use of the usePosition hook,
which is the recommended way to compute this kind of positioning.
Part-of: odoo/odoo#135188
**Before this commit**
The usePosition hook takes two arguments:
- the target element (could be a function returning an element)
- the positioning options, which are optional.
This API is a bit weird for these reasons:
- the target argument's type is variable
- the "popper" option is not very meaningful and has a
default value of "popper", which is not clearly stated
**After this commit**
The usePosition hook now takes three different arguments:
- first is "refName", which is the reference to the element to position
in the template
- then is "getTarget", a callback that must return the target element,
- finally the "options"
Part-of: odoo/odoo#135188