Recommended by GitHub's repository alerts.
We normally stick as close as possible to the version we depend
on in the official DEB packages. This in turn depends on the version of
Debian stable at the time of release - for 9.0 that would be Debian 8
(jessie) and thus Pillow 2.6.1.
However Pillow versions before 3.3.2 and Jinja2 before 2.8.1 suffer
from a few issues that could lead to crashes of Odoo workers.
The bugfixes have been backported in the DEB packages for Pillow,
so users of Debian/Ubuntu LTS versions won't be affected if they are
keeping their systems updated.
However it's worth an exception to our rule for pip users.
Like invoices, a reference is now computed on sales orders.
The configuration of such reference is done through the Wire Transfer acquirer.
The usability of the communication feature (on invoices/SO) has been a bit improved to be more clear.
Was task: 1870121
Was PR #26152
avoid race condition when refresh of /shop finish after the search click.
Now we start on the search page directly, that make tour faster and that
don't remove any usefull test, since the purpose of this test is to test
coupon and not the search view already tested by others tests.
When you need to fast review all properties of a model, mostly the
fields it is really anoying go to all the technical path which has all
the information already.
The previous "View Fields" action was very messy.
My proposal is simply instead use a dialog which is almost useless open
a normal vie (a little improved) which allow us audit completely
everything.
Remove the previous dialog, this will not be used anymore.
Closes#26364
From this rev., the empty value isn't available in the options of
required selection fields, thus preventing the user to unset it.
Related to task #49262Closes#24404
- Create a product A tracked by S/N
- Get some stock of A
- Create a SO and sell 1 unit of A, confirm
- Go to the picking, validate
An error message forces the user to manually encode the 'Done'
quantities.
This step is not necessary, since the user will still get a message
notifying him that the reserved quantities will be used as done
quantities.
opw-1873180
When a subview is defined in a form view, the fields_view_get
extracts it from the global view arch returned. So extending the
field_view_get does not work to change label on subview.
This commit make this work by extending private implementation
instead.
Task #39079
Do not replace the day value without notifying the user.
In undetermined circumstances, a fiscal year last day and month can be
replaced by the default December 31st value. Since all settings are
re-written for any setting changed, this is likely to happen in the back
of the user.
Moreover, the `_verify_fiscalyear_last_day` is not correct since it
doesn't accept February 29th, while `compute_fiscalyear_dates` handles
it.
opw-1867978
opw-1873260
This commit brings a Pie Chart Widget that allows to visualize
simple information on in a single pie chart.
For now it is only used in dashboard view but it could also be
used in another view that uses a basic renderer.
An element with tat widget with attribute name 'pie_chart'
can now be added to the arch view.
Three keys should also be provided in the attribute 'attrs':
- measure (determines the field to aggregate on)
- groupby (determines the field used to group data)
- title (determines the legend of the pie chart)
Task Id: 1835644
A lot of new features have been implemented in search view
but autocompletion was forgotten. This commit fixes many
small problems that were introduced:
- synchronization of facets created through
autocompletion with filters and groupby menus
- filters created through autocompletion can be saved
A previous commit [333ac27] has introduced a new widget TimeRangeMenu
that allows to create two sets of data to compare relatively
to a given date or datetime field.
This commit allows the graph view to render appropriately two
sets of data as would be expected in the different modes.
Task Id: 1835644
A previous commit [333ac27] has introduced a new widget TimeRangeMenu
that allows to create two sets of data to compare relatively
to a given date or datetime field.
This commit allows the pivot view to render appropriately two
sets of data in a unique table. In comparison mode, instead of
one column, three columns are created. One contains the
aggregates from the data of interest, one contains the
aggregates from the comparison data, and the last one contains
information on the data variation (expressed in percentage).
Task Id: 1835644
This commit introduces a new widget 'TimeRangeMenu' used in
the search view. It allows a user to easily:
- search data with a given date or datetime field value
in a specified period of time
- compare the data of interest with data of the previous
period or the previous year.
The time range menu is available in the search view when one
of the four following view types is instantiated:
graph, pivot, cohort, or dashboard.
Task Id: 1835644
The field move_dest_ids is now defined in purchase_stock (since the split at
rev 8d4609a1db)
The line was added in purchase at f6b3247c31 in 11.0 but incorrectly forward
ported.
This commit only moves the code to the appropriate module.
[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
The items were hardly readable in the xml because they were in a random order. They are now logically sorted by parent relation and sequence.
Unnecessary groups were also removed (child groups when parents already had more restrictive groups).
PR: #26345
Task: none
The current implementation of odoobot is stateless, making him a little dummy.
Adding a state on the user allow to be sure that the user don't skip a step,
or loop back to a previous step.
States also allows odoobot to repeat the question when the user don't give the
right answer.
A quick modification asked by FP before freeze, in order to change the field
type in time.
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
XavierDo