Purpose
=======
Product attrivutes can now have custom values.
These values are specified by the user during the SO creation.
They are also available on the webshop frontend.
Specification
=============
add a new mode to generate variants as they are added to the order/cart
- ability to define attribute extra prices & exclude combinations
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.
Purpose
=======
When several warnings are raised, in an onchange for example, the warning
messages and titles are concatenated on the dialog, even if they are
exactly the same.
Specification
=============
Don't concatenate warning messages if they are exactly the same.
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)
This commit adds various fixes to blog and forum:
- Some templates were mising a name, resulting in ugly page title
(eg: forum_all)
- Latest Blogs page was checking seo keywords to display tags, maybe it was
coming from an old tag implementation that used seo keywords?
- If only one forum, land on it directly when accessing /forum, like blog
does
- ..
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
This gives the user an overview of the possible actions,
including those he currently does not have installed.
It allows him to quickly install the missing applications
without having to go on the backend.
The commit also improves the existing actions:
- correct handling of the actions deferred
- add some translated terms
PR: #27110
task-1885419
Sometimes we try to append a query string to an url, but if there is a remaining anchor, the query string will not be added at the right place.
The title and description tags might not exist (translated page) so it would be displaying false instead of empty string.
PR: #27110
task-1885419
How to reproduce
* install website_theme_install;
* go on Apps -> Apply scheduled upgrades;
* Hit Cancel;
* there is a crash because somehow when writing on module self is a void
recordset and self.name is therefore False and cannot starts with 'theme';
This commit fixes that by ensuring self is not void before checking its
name.
Somehow, having theses 2 new `website.page` records created separately from
their `ir.ui.view` would throw an error in dev-xml when installing website
module.
A task has been created in website team to track the origin of this bug.
In the meantime, this commit will avoid the traceback by creating the view
inside the page record. As the page's view is not intented to be inherited, it
is the best way to write it anyway.
Odoo evolves and its coding guidelines too.
This commit :
- put some news guidelines, case to take
into account when making new dev
- update some guidelines that are difficult
to applied in the real life
- remove deprecated stuff (RML report, ...)
- remove references to old
api mainly, since all new dev must be done in
new api
Task #1817988
156955de6b introduced a new property `website_meta_og_img` in
`website.seo.metadata`.
When rendering a template, `render()` is calling `get_website_meta` that will
end up reading `website.seo.metadata` fields.
But `website_slides` module is overriding `check_field_access_rights` to allow
partial read on the record.
The new `website_meta_og_img` was missing from the allowed fields, thus
crashing when an user without the required slide's group would try to read the
slide.
Purpose is to show people shortcode actually exists. Moreover having
im_livechat_mail_bot requires to have a least one shortcode available
in order to complete the onboarding with odoobot.
Commit linked to task ID 1887949.
Otherwise tweaking it requires an access to the database or making a custom
view which is not the most user-friendly way of doing it.
Commit linked to task ID 1887949.
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.
Currently check_access_rule method checks for record rules and raises an error
if there are either missing ids (deleted records) or forbidden ids (records
hidden due to a record rule).
Purpose of this commit is to have a method allowing to filter a given recordset
and receive only valid records. Its implementation is basically a refactoring
of check_access_rule.
This commit is linked to task ID 1856417 and PR #26565.
After a module upgrade, validate the architecture of the module's views that
are impacted by updates, but have not been checked yet. Before this patch,
views were checked twice on average.
This patch speeds up the installation of modules by about 15% without demo
data. With demo data, the speedup is around 10%.
When rendering a report (`render_qweb_html` for example), one can pass `data`
(a dict of values, used for the template rendering).
This dict was overriden in `_get_rendering_context` if the method
`_get_report_values` on the report model was not correctly written.
This was causing an issue when rendering a report in Studio because the `studio`
key was overriden.
Now, the `data` dict is updated (instead of replaced) with the rendering context.
Aurélien Warnon