[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
Impacted modules: hr_timesheet, sale_timesheet
When task is changing project or sale order line, we
don't want anymore to change the linked timesheet.
We now consider a timesheet is done in a specific time
at certain condition that does not have to change when
the environment is modified afterwards.
So, a timesheet linked to an analytic account for a
certain project on a task (and mybe linked to a SO line)
will still be linked to the same object if the task is
billed with another SO or move into a new project.
The idea is task actual configuration (project, AA, SO
line) are the default value at timesheet creation. As
consequences, timesheet from another project can be linked
to a task that does not belong to that project.
Project and task can be modified thougth the UI of timesheet
app. SO line and analytic account of a timesheet can not
be modified as they are more sensitive field (in a business
point of view), especially for invoiced timesheets.
This commit revert opw-1803811, as at that time the
'inheritS' between project and AA was still effective,
and there was only one billable type (task rate) for
task. The introduction of 'employee rate' billing type
will complicate timesheet transfert.
Tasks #34703
Purpose
=======
Sometimes we could want to send a notification to the author too.
Like in the onboarding bars, where we send a sample invoice to the administrator.
He's the author of the message, but the goal is to send him an email to check the
full process when sending a sales order/invoice by email to a customer.
Specification
=============
For that purpose, if a key 'mail_notify_author' is set on the context when
sending the email, then notify the mail author.
Purpose
=======
Clean some stuff on the onboarding bars:
- Payment setting should be activated in sales settings if a payment acquirer is
activated from the sales bar, otherwise the customer can't pay with the acquirer
- No email is sent with sample documents -> sending to yourself using the chatter doesn't work...
- Select "sign online" by default
- Improve payment instructions
- Improve the default thank you message on payment acquirer accordingly (when no bank defined)
- Choose a custom payment method -> mark the step as done
- Improve buttons wording:
- Put a pointer cursor when hovering on done steps
- Fix typo : instructions -> Instructions
- Fix layout issue on tax screen
When using a paper format to print a report, one needs to pass the format to
wkhtmltopdf (with --page-size, e.g. "A5").
The information about the print page size (width, height) has been added on the
paper.format model. It is used in Studio to correctly display the report
preview in HTML without printing the report.
Before this fix, in studio when the user select the field then focus out
then focus in and selected a child field, an exception is triggered because
the last page is visible but the data are removed.
A test in enterprise (web_studio) is added with this commit.
Fix the issue of the t-esc display the content before the tag.
Activate qweb qunit test (same test for the JavaScript and python)
Use the same behavior as python: keep attributes order, and display content
as default value when the variable is falsy.
Before this rev. one could set the report layout on the company using a
hardcoded list (background, clean, standard, etc.). Other modules (typically
accounting modules) could add options in this list. The used template was built
on the layout key.
Now, the layout is a many2one field to a newly created model `report.layout`,
which is linked to a view with the layout architecture.
This gives more control to customize reports and create a new layout (without
creating a python module that extend the layout selection).
Following the new studio features, the use of t-call in templates with
the id occurs. Doing the verification of the integer type of the template
in addition to checking whether the value of type string is a number or
not should be done at different levels. It is therefore simpler to ensure
that the value is a number or an xml_id in compile which is the entry
point of the render and t-call.
The cache made on compile does not change because we have no case where a
template is called with a number of type string in addition to being
called with an integer.
In Studio, users can create views, reports, etc. which do not have an
xml_id (no record in 'ir.model.data' from import/install).
After this modification, the template can use the t-call using a readable
key on newly created views.
There is now an option `continueMove` that can be used to extend a previous drag
done in this function.
The option `position` has also been extended to take an object (to precise the
move position).
The option `digital` has been added. It allows to display "01:00" instead of "1
hour". This behaviour was implemented in a report (timesheet) but the logic
was done in the XML, which is not adequate.
This commit also allows to have a negative value for this widget.
With the report editor in Studio, some reports were not easily editable (not
idiomatic XML, too much Python logic in XML, etc.).
These reports have been cleaned up.
When using positional clicks (among other examples) in tests, a previous failed
test might affect a next one because the assert failures are displayed on the
top of tests.
The FieldMany2ManyTags uses FieldMany2One in its implementation.
Before this commit, the field attributes were not propagated to the sub field.
In particular, the attribute `can_create` is useful to be propagated.
If wkthmltopdf silently raises an error without any error code, there was
previously nothing displayed to help debugging.
The error is now logged as a warning.
Sébastien Theys