- 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.
This new helper is meant to solve the following use case: serialize a number
of concurrent rpcs while skipping the rpcs that arrive in between the mutex.
In both test util functions (`dragAndDrop`) and tours, using elements in iframe
was not supported.
As a jQuery selector won't work with an iframe, when using a selector like
`div.o_my_class iframe p:first` the tour manager will split the selector, which
will result to `$('div.o_my_class iframe').contents().find('p:first')`.
When compiling the qweb template, if an error occurs, an error message is
displayed with the corresponding failed node.
This messsage was not always correct because the node is modified in place
during the compilation proccess.
The template is now re-read before displaying the error.
Each qweb widget should now explicitily define a method
`get_available_options` which specifies all options used in the widget
rendering.
The options are a dictionary with the option as key and the option type as
value (e.g. string, integer, array, model, etc.).
This is used by the Studio report editor (to customize widget options) and parsed
in JS.
A new `filter` option has been added to filter fields with an optional function.
A new `order` option has been added to sort displayed fields.
The `followRelations` options have also been extended to take a function.
This change greatly facilitates inheritance and xpath and avoids having
to rewrite each time the entire dictionary of t-options.
e.g.
<span t-esc="5" t-options="{'widget': 'char'}" t-options-widget="'float'" t-options-precision="4"/>
the t-options-xxx overwrite the dict. The rendering became:
<span>5.0000</span>
Before this change, the reports were generated in editable mode for branding
to be applied. The branding is used to cut the report and add on each
selected record for generating the pdf.
Applied branding and editing options takes a useless time and branding
was also applied by widgets even if branding was not requested.
When reading the metadata of a record, ensure the order is consistent.
The retrieval of ir.model.data is now done using an order=id query
Use the ORM to retrieve ir.model.data instead of making an SQL to clean old
code (introduced at b3b22afc68)
Closes#25658
This commit includes various improvements:
* 'Event' menu is moved under 'Reporting' menu and will be visible without debug
mode
* view sequence has been changed to pivot, graph, list, form
* new filters have been added:
- Unconfirmed
- Confirmed
- Attended
- Registration Date
- Event Start Date
- Attended Date
Task 1854339
Warehouse's routes, locations, picking types and
sequences are now generated on create or with a post
init hook for exisiting warehouses before module installation.
Before the init hook, warehouses created before mrp module installation
do not have a specific sequence number for manufacturing and they
shared the same sequence production created in data.
The purpose is to define a better sequence order by default.
Rules's name generation is base on their location and warehouse name.
Since locations order is not always the same than the alphabetical
order, we would rather use the id.
qsm-odoo