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
This adds a button to import several bills from the accounting dashboard: will create a new vendor bill for each, with the file attached to it. That file will be visible in the chatter (in enterprise) and allow easilly completion/encoding of it. This task also comes along with the import/export of xml files attached to the PDF files created from the invoice report.
Was task 1859277
Was PR #26339
* Make phantomjs logging clearer by logging within the test case's
module, not odoo.tests.common.
This way, a tour in e.g. point of sale is clearly logged as that,
rather than be logged as odoo.tests.common.phantomjs and require
hunting which module/test we happen to be in.
* Clarify tagging causes for exclusion of selection of tests.
Math.sign(comparisonValue) * comparisonValue being equivalent to
Math.abs(comparisonValue) in all the cases that we consider, we use
the latter formulation that is available in ES5.
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
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
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
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
[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
When a project become billable, the employee can now timesheet
on a same task, at different rate.
The project should be linked to a SO, and the mapping between
the employee and the SO line will be done using 2 mecanisms:
1/ task rate: the SO line set on the task is chosen for any employee
timesheeting on the task.
2/ employee rate: a map exists on the project, matching employee
with an SO line from the SO of the project. If the employee is not in
the map, the fallback will be the SO from the task, or the one from
the project.
This makes the SO line on the task always visible.
See subcommit for more details.
Task #34703Closes#26111
When a project become billable, the employee can now timesheet
on a same task, at different rate.
The project should be linked to a SO, and the mapping between
the employee and the SO line will be done using 2 mecanisms:
1/ task rate: the SO line set on the task is chosen for any employee
timesheeting on the task.
2/ employee rate: a map exists on the project, matching employee
with an SO line from the SO of the project. If the employee is not in
the map, the fallback will be the SO from the task, or the one from
the project.
This makes the SO line on the task always visible.
The billable type of a project depends on if the map is filled
or not. There is 2 ways of making a project billable:
- project is created from SO confirmation (depending of product
configuration)
- through the wizard "Create Sales Order": a SO will be created
and the project will be associated to it.
The subtask should follow the configuration of its parent
project (and not parent task).
Task #34703Closes#26111
The config of a project will become more
important and usefull for project manager, so
adding a shortcut from the overview to setup
correclty its project makes sense.
This commit adds this button on the overview.
Task #34703
We want to set the sale line of the parent when changing the subtasks parent
but not force changing it when modifying the SO line of the parent task, and
we have to reset (empty) so line on subtasks when changing the customer of a
task to avoid no seeing the current SO line in its domain (dropdown) since the
customer has changed.
Task #34703
For futher developpement, the notion of billable
type of a project and a task will appears. This commit
introduces this notion to make clear the case 'task
rate' was already covered.
Task #34703
Sébastien Theys