In order to restrict some uom field to some uom category, it is required to
add a measurement type on uom.category. Also, this will lessen the use of
master data.
Some technical justifications:
- measure_type is not required, to allow people creating their own
uom.category. Those ones will not interfere with addons business.
- measure_type is unique: we restrict to only one category containing
time, weight, ... in order to avoid mismatch category during conversion.
(2 different weight categories can not be converted).
- measure_type on uom.uom is stored: to allow search and domain on
field, we need to store it. Usually, UoM are not updated every day,
and the number of uom in a database is not that important.
To illustrate this mecanism, a domain is added on
'project_time_mode_id', in project module. This field
is use as timesheet default uom, and we obviously want to
restrict it to time category (timesheeting in liter does
not make sense ...)
Task #1820076
Since e9734f4975 assignation is now a notification sent in the
inbox or by email to the newly-assigned responsible. It is therefore
considered as not necessary to link a subtype to the assignation itself.
Indeed having it logged in the discussion history as a classic tracking
in addition to the notification is considered as sufficient.
In project module the task opened subtype was linked to task creation and
task assignation. This subtype is now used only for task creation. It also
fixes a strange behavior. Changing assigned user in an ongoing task was
trigerring the task opened subtype which was strange. This is not the case
anymore.
This commit is related to task ID 60790. Closes#23244 .
Moves UoM models, test and data to a new addon in
order to be able to use uom without product.
A simple example is be to be able to use UoM for
timesheets.
This commit only move code, and adapt xml ids
without chaging any feature or functionnal
behavior.
Note: 'product' module now depends on new
'uom' module.
Purpose
=======
In a business point of view, it make no sense to merge record. if someone want really to merge record they have to do this manually to think about all corner case. What about id sent to the customer ? what about timesheet ? what about business ?
The idea of the task: remove this feature in both app, project.task and in helpdesk
Specification
=============
Remove both features
"Merge Selected Tickets" in helpdesk
"Merge Selected Tasks" in project.task
Impacted modules: project, rating_project,
sale_service_rating and website_rating_project.
Removed modules: rating_project and sale_service_rating.
Move code to empty 'rating_project' module, in order
to kill it.
Code is not modified, simply copy/paste at the right
place in 'project' module code.
However, 'enable rating on task' options is convert
into a res.groups that can be activated from the
project settings.
Purpose
=======
User tests have been made by the Product Owners team. It showed that the planners are not used by new users on Odoo due to several reasons (They are too static, too heavy to use,...)
Specification
=============
Remove the module and its different applications. The onboarding on the business flow will be improvement in the weeks to come.
Not used since a while, remaining of old res.request. Requests have been
removed at 881a76dbcf . Links have been kept because still
used in some reference fields. It seems the last use was in OpenERP v9.0
in crm_claim module. As links are not used since a while let us get rid of
it.
This field was needed because a rating could be sent to a customer for a task or an issue.
This was buggy, because if a template was set on a shared stage between tasks and issues, the rendering could crash, generate an email with wrong piece of information, and so on.
By removing this field, we can also remove some ugly code that was needed to make that distinction.
According to usability experts configuring a sales team alias should
be done directly on the sales team view and not through an hidden
and strangely configured settings.
This wizard allows the users to merge some task in a new task or an existing one
A user and a project are taken by default but may be configurable on the wizard.
The other tasks are archived. A message is posted on the tasks to report the target and a message is posted on the target to report the origin tasks.
Xavier Morel