* web, website
- Introduce gray color palettes (needed for themes migration)
- Synchronize BS4 color maps with individual variables (see comments
about this in the code).
- Review alpha/primary, beta/secondary matching:
Before this commit, we decided that the common way to define a color
palette was defining primary, secondary, gamma, delta and epsilon.
alpha and beta were then forced to primary and secondary without other
possibility.
The new system makes more sense:
1) define alpha, beta, gamma, delta and epsilon
2) primary and secondary will automatically be set to your alpha and
beta (allowing to style the default UI with BS4-independant
variables)
3) if you are not happy with (2), you can define primary / secondary
in your color palette so that they are not automatically set to
alpha / beta
This commit also changes what classes the editor uses. Background colors
and text colors will now use alpha/beta/gamma/delta/epsilon (not primary
and secondary anymore). For buttons, all the possibilities are suggested
but color duplicates are hidden (so if your primary and alpha are equal,
only one button color is suggested).
Now that this field is computed (true if value), once the user check a feature, it is required to fill in the field.
Before this commit, you can click on checkbox, and save without key in field, and a refresh checkbow was again unchecked.
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
This behavior is useless in the front end (`clone_page`) as people cloning a
page will leave the page with copy in the page name without even noticing it.
Furthermore, creating or copying a website will bootstrap (clone) some pages,
suffixing all of these page by 'Copy'.
`main_object_request` was added in the navbar widget.
It would not work with `PageManagement` widget as it is added in the
website_root widget and not the navbar.
Moving it to the website_root will make the event accessible when triggering up
the event.
The edition dropzones for the bottom of the main content and the top of
the footer content are at the exact same locations.
Until commit https://github.com/odoo/odoo/commit/514722d783d504151b6b835375de036eda88279f,
when trying to drop a snippet there, there were two cases:
- The user drops a snippet above/below the location -> the snippet
is added to the main content (as the code searches for the nearest
dropzone, and always return the first one in the DOM if several are
found).
- The user drops a snippet around the location, seeing a snippet preview
-> the snippet is added to the footer content
With the mentioned commit, the second case changed: the snippet is now
also dropped in the main content. While this is more logic, there is
no way to drop a snippet in the footer anymore. Adding a border on top
of the footer content solves the problem for now (as the dropzone will
now be at 1px different location).
It was easy to mess with the footer unintentionally when dropping
snippets in the page. Now we only allow one "main" snippet in the
footer, solving the problem.
-Some tests where moved without addapting the path to them:
path is now update and tests fixed.
-A picture was removed in commit 4dce6cc98b but
still referenced in template website_twitter_snippet.
-A test was missing a data leading to the wrong path to image beeing loaded
With this commit now user can set custom meta image from the seo dialog. If the
user sets such image then it will be displayed when the user shares that URL in
social sites.
By default, it will show the list of images used in the current page.
Alternatively, user can use media dialog to select/upload images. By default, it
will take the company logo as a meta-image.
We also improved how custom meta tags are handled for different pages, Now we can
set custom meta tags based on the model and we can override '_default_website_meta'
method in case you want to change default meta values from the specific model.
e.g. For products displayed on the shop, if we want to change the value of
og:image to product specific images instead of default logo
In future, it will be used to add model specific metas like og:price, og:currency
We passed 'website_company_id' in frontend session info because we display
company logo in dialog for all pages. We can't use /logo.png as it is not
updating in multicompany and multiwebsite.
task id: 1835370
Closes: #25430
* social_media
- Remove action server demo (out-dated and buggy)
- Remove website app / themes app actions (useless)
- Move demo social media to the social_media addons
- Use same contact us page for demo website 2
- Improve edition of contact us and about us pages by using snippets
as default contents
- ...
Placing a list-group inside an element whose text color is forced is
buggy as the background of list-group items is forced to white and
the text color left untouched.
Before BS4 migration, Odoo was not very consistent and used mainly
btn-sm buttons and btn-xs buttons. We took advantage of the fact
BS4 removed the btn-xs class to convert our btn-sm to standard btn
and our btn-xs to standard btn-sm.
While this is perfect in theory, the new btn-sm class does not
generated small enough design for us. This commit changes the BS4
standard style for our website, making btn-sm smaller.
[MOV] move sale_payment into sale
=================================
Almost all use cases of sale require sale_payment down the line.
There is only one case which does not: using sale_management without website_sale or website_quote.
However, since we want to move most of the features of website_quote into sale_management, moving sale_payement first will make the task easier.
[MOV] move website_quote into sale and sale_management
======================================================
We want to use some features of website_quote without having to install the whole module.
The main issue with website_quote was that it had a requirement on website.
What is common to website_sale and sale_management has been moved into sale. This is primarily the sales order portal view.
What is only related to sale_management has been moved into it. This is notably: sales order templates, optional products, sign and pay, ...
Everything that requires website has been moved into a new module named sale_quotation_builder. This is related to using the HTML builder to customize the quotation view.
Models, files and routes have been renamed to better convey their purpose and to follow guidelines more closely.
[IMP] merge sales order portal views
====================================
The old sales order view on the portal has been merged into the one from website_quote. The new view contains features of the two.
A lot of fixes and improvements have also been done, related to BS4 issues but also to improve the sales order view in general.
[IMP] add new settings
======================
The commit adds new settings related to activating the features that previously were activated by installing website_quote.
PR: #26345
Task: 49205, 1838924
It doesn't exists anymore in enterprise version.
Combinaison of website_publish , website_page, and multi website allow to
partially replace it.
AB testing will be back in a later version after a big refactoring.
Allow to override the asset url generation to add in the path the website ID
and avoid continue invalidation cache and bad cache by browser.
Asset url is:
"/web/content/{id}-{unique}/{extra}{name}{page}{type}"
with:
id = attachment id
unique = hash
extra = allow to add custom params eg: website_id/ or rtl/
name = filename
page = used in css to split rules 4095 / file
type = css|js
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
From now, when you install a theme, it load the data from xml to template
table theme [ir.ui.view|ir.attachment|website.page|website.menu].
Data are only copied from this template table into the real table when you
choose a theme on a website; Making them website_specific and with a link
to the original to allow futur update.
A special case is done to create theme.ir.ui.view when you are installing
a theme, even if you continue to use template tag to create quick view.
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
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>
google analytics, google map api key, ... can be set by website
Remove useless duplicated label
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
In some case like for website_menu or res.partner from the sale_order form view
it is nice to know easily on which website this record is depending.
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>
Now we can see which specific page override wich page when page are sorted by url.
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
This implements support to administer multiple websites. Although the
core functionality already existed, managing multiple websites was
fairly technical.
In the interest of database updates and migration this attempts to
keep duplicated data to a minimum. To do this the usual generic
records are rendered unless some website-specific record exists that
replaces it. Copy-on-write (COW) is used to create these
website-specific records. Through this mechanism creating a
website-specific record is delayed until necessary. A COW mechanism
has been implemented on 4 models: ir.ui.view, website.page,
website.menu and ir.attachment. These COW mechanisms are activated
when editing data through the website (aka frontend). These frontend
edits (e.g. with web_editor) will be website-specific, possibly
creating a website-specific record when necessary. When editing data
in the backend nothing special will happen, even when editing a
generic record. Note that because of this mechanism also facilitates
the ability to create new, uncustomized websites because the generic
data is kept.
Support is provided for a website to have any theme. Themes are fairly
complex to handle. Standalone themes can depend on other standalone
themes (e.g. theme_beauty depends on theme_loftspace) and themes
usually modify some data of the themes they depend on. Because a theme
can be installed on multiple websites, using website_id m2o fields
does not work well. It would require duplicate data, making updates
and migration harder. Because of this, data for themes (ir.ui.view and
ir.attachment specifically) have a theme_id m2o. website has a
theme_ids m2m that identifies all theme modules currently installed on
it. Through these fields we figure out what to render. A theme is only
fully uninstalled when it's no longer active on any website. The
advantage of this approach is that upgrading or migrating theme data
is no different from the single-website case.
The website.published.mixin class was modified to handle multiple
websites. A wizard was added in the backend to easily manage this for
multiple website.
Although not used anywhere in this commit, a 'website_id' variable has
been added in the evaluation context of ir.rule. It allows to easily
make any model multi-website aware, all that's needed is a custom
website_id m2o field on a model and a custom record rule.
itertools' groupby function expects the iterable to be sorted as
hinted to in the documentation:
"Generally, the iterable needs to already be sorted on the same key
function."
When running groupby on an unsorted iterable non-adjacent duplicates
will remain:
>>> from itertools import groupby
>>> [e[0] for e in groupby([1, 2, 1])]
[1, 2, 1]
Because of this filter_duplicate would occassionally return
duplicates. To resolve this sort on the key field. Afterwards sort the
result on the usual inherit order: (priority, id).
Warning (mule): Invalid coding system ‘ascii’ is specified
for the current buffer/file by the :coding tag.
It is highly recommended to fix it before writing to a file.
* web_editor, portal
This commit introduces the first page options: header overlay and color.
The website builder is improved to allow the management of those. With
this commit, users can now click on the website header to make it go on
top of the first snippet, with a chosen transparent color. This is a
configuration that can be done on each page individually (as the feature
is very dependent of the first snippet on the page, this is typically an
option for homepages).
task-32155
- Before this commit, when we asked to (re)start animations on an
element, we checked the animations to be started on the element
and started them after destroying the animations with the same
name which were already running on that element. This is in fact
not correct. Indeed, if an animation was running on element but
that the conditions that made the animation start are now gone,
asking to restart the animations on that element should destroy
the deprecated ones. (e.g. an animation "A" is to be started on
all elements which have a class "a", if we remove the class "a"
on an element then restart animations, the animation "A" should
be destroy). The implementation is in fact even simpler: when
asking a restart, a full stop is performed then a simple start.
Note: this does not need to be a fix as multiple animations on
a same element was recently introduced and the described case
never occurs with current features.
- When stopping the animations on an element, stops the animations
of all its descendants too.
- Add an helper method in the `SnippetOption` class to restart the
animations running on the `$target` element.
* web, web_editor, website_hr_recruitment, website_mail_channel,
website_mass_mailing
- Review all snippets and add new ones
- Add lots of new options
- Use odoo colors as default theme colors
task-38878
qsm-odoo