Some of our new snippets for 12.0 uses parallax. Those were not using
the exact structure required by parallax which *may* lead to unexpected
results when playing with the related options.
closesodoo/odoo#28299
Future update will allow to save oe_structure editions in an inherited
view instead of editing the original view in place. The condition is
to have an id on the .oe_structure element which contains the
'oe_structure' string.
Setting a black low-transparency filter on a parallax element was
leaving the text color black too as the filter did not act as a
background color. Now the filter is computed from the parallax
background color.
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
Before this commit it was attached to the form, in case your banner was
customized to have the font-color white, the text modal become white on white.
Now we attach to body, to don't have custom design from parent div.
This commit closes opw-1881280
[FIX] web_editor: adapt col size to avoid too small select
We should avoid col-md-3 in col-md-9 as the menu dialog is instanciated at 2
places:
- When creating a link in the editor
- When editing website navbar menu
In the second case, there is a hack in `content.js` to remove `modal-lg`
lowering the width of the modal and making the select too small.
[FIX] website: lower navbar font size
With BS4, font-size of navbar element went from 13px to ~17px (rem unit
computation).
14px seems better than previous 13px as the frontend content size is
higher than the backend one. Thus, 13px looks too small in contrast with the
frontend page content.
[FIX] website_crm_partner_assign, website_customer, website_membership: fix layout
This commit fixes multiple layout issues, mainly by aligning code of the 3
modules:
- Add margin right to avoid text to be against image
- Using image_medium everywhere
- Fixing search input width
publish toggle red + odoo primary is weird -> gray
navbar now has a background & float-right not working since flex
-> remove navbar class, use d-flex and ml-auto so the right element will be floating since using all available width
task-1878150
Reorder res.config.settings for website
Make website_id in no create in most view
Revamp res.configsetting and view Form simplified
Transform old 'useless' stored field for presentation by computed field.
We can consider that if there are not key, feature is disable.
Co-authored-by: rde-odoo
Co-authored-by: jke-odoo
Regenerate all child translations based on the .pot
Remove the terms that are either equal to the parent, either equal to the
source term.
Remove empty translation files
As fbbf24f58a introduced multiwebsite and `website_published` became a
related and/or a computed field (depending of the mixin), we should not order
on this field as it is not on DB anymore.
We now have the field `is_published` that replace `website_published`.
In event_sale it is possible to have one product representing several tickets. But before this commit, on the sale order and invoice the client only saw the name of the product and didn't know which event/ticket they subscribed to.
The goal of this commit is to overwrite that behavior whenever a sale order or invoice line is related to an event ticket, to show the ticket name and event name instead of the product name.
Technically, the following changes have been done:
----------------------------------------
* various: add a method to compute a default name for a SaleOrderLine, based on its product
I added the method because the code to compute the name was duplicated in several places. This will make it more consistent.
Moreover this gives the option for modules to override the method to define a custom name as necessary.
----------------------------------------
* event_sale: compute a consistent description for a SaleOrderLine based on an EventTicket
The description will be the same whether the sale order comes from the front end or the back end. It takes into account the customer language.
The default description will be computed as follow:
1. The ticket name should be the first line of the product description on the SO.
2. The event name should be the second line of the product description on the SO.
To compute the ticket multi-line description we decided to ignore entirely the product name and the product description_sale because they are considered to be replaced by the ticket name and event name.
We also ignore them because the work-flow of creating a new event does not lead to filling them correctly, as the product is created through the event interface.
----------------------------------------
* event_sale: improve sale order line and event registration views
It was possible to select a ticket related to a product before an event was selected.
This is typically the case for tickets defined in an event_type but not in an event.
The ticket field is now hidden until both the product and the event have been selected.
This way we are sure the selected ticket will belong to an event and not an event_type.
We reset the ticket on event change because we don't want the user to be able to select a ticket belonging to the wrong event.
We also improve here the comments of the related on-change methods.
----------------------------------------
* website_event_sale: update views to show ticket name and event name
The standard behavior was to show the product name in several places instead of the sale order line description.
However, for event tickets, we don't want to show the product name, but the ticket name and event name instead.
----------------------------------------
* website_event_sale: add ticket on confirmation page
The ticket name was missing from the registration confirmation page (shown when the ticket is free and/or the user paid with a direct method). This is now fixed.
----------------------------------------
Task: 1837987
PR: 25819
Set up env & tools for module website multiwebsite (blog, event, sale..)
website_id in modelConverter and ir_rule
add _compute_domain_keys to have a different cache per website
or rules would not be correctly website_dependant
eg: blog 1 on website 1, blog 2 on website 2
access blog 1 from website 1 => can access -> normal
access blog 1 from website 2 => can access -> should crash because (ir rule)
split mixing website.published.mixin and website.published.multi.mixin to have
website_id only on last one.
multi mixing will:
- override website_published compute to take current_website into account (not in backend)
- force website when clicking on published in backend
- website blog, website_sale, website_event, website_forum, website_slides are now multi website
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
Fix bug from the initial poc of JOV
Fix menu creation
- creating a menu would create a 'container' menu in the DB (.create is call without website_id)
then writing on it would copy (if condition to cow) the menu with a website_id leaving the first
one as a menu container unused.
- website_menu should always have a website_id
we dont want to support the multiwebsite system that allow to have generic/specific menu
unlink/write is useless now since we always have a website_id
Make unique_path website dependent, 2 distinct website can have a page with same name
Make Sale report multiwebsite compliant
Make website_id on sale_order / account.invoice as a related stored from partner_id.
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
From this commit onwards, Date fields will return datetime.date objects and Datetime fields will return datetime.datetime objects, this implies a number of things that are clearly explained both in the ORM API for master.
This commit also introduces a number of helper functions for dates and datetimes that are exposed in tools.date_utils and fields.Date[time], explained in the documentation as well.
Task-ID: 47189
Odoo Translation Bot