Before this commit, when the portal user changes the stage of a task and
the new stage contains a rating template email, he got a traceback
saying he has no access to `mail.template` model.
This commit fixes the issue by sending the email in superuser when we
are sure the user can write on that task.
Steps to reproduce:
==================
1) Enable the rating feature in the settings of Project App
2) Create a Project A and edit it to enable the rating feature on that
project and select "Rating when changing stage" (if it is not already
the case)
3) Set a rating email template on a stage of the project
4) Create a new task and save
5) Change the stage of that task to the stage contained the rating email
template
Actual Behavior:
---------------
A traceback is occurred saying the user has no access to `mail.template`
model.
Expected Behavior:
-----------------
The stage of the task should be changed and the rating email should be
sent.
closesodoo/odoo#99248
X-original-commit: c5093988411e5697f49ca2a128e93203c2d6aac9
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.
This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.
This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.
As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.
closesodoo/odoo#94337
Related: odoo/enterprise#28936
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Currently, portal followers of a project and its tasks are removed when
the project visibility is changed to something else than portal.
=> We want to keep the behavior, but only when changing the visibility
from portal to something else.
When the project visibility is changed to portal, we currently add
its customer to its followers.
=> In that case, we also want to add the customer of the tasks to the
followers of the corresponding task.
When the customer of a project in portal visibility is changed, the
new customer is added to the followers of the project.
=> We want to remove this behavior.
When a project is created with a customer and the portal visibility,
the customer is added to the followers of the project.
=> We want to remove this behavior to avoid mistakenly showing a project
that is not ready yet to the customer.
This commit implements those changes, and also adds a warning when
changing the visibility of the project if that change will automatically
add/remove followers to the project and its tasks.
Related: https://github.com/odoo/enterprise/pull/25800
Task-2812551
closesodoo/odoo#87747
Related: odoo/enterprise#25800
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, when the current user is in project sharing and see
the form view of a task with at least a subtask. He cannot create
another one because of an error in the `_compute_portal_user_names`
method. Indeed, it is because we want to update the cache to get the
user_ids of the task related since the portal user cannot see the
users assigned to the task since he cannot access an internal user. This
update cache is made by calling the `_read` method but this method
checks after having fetching the data if the self is equal to the
recordset fetched. If the `self` contained newIds, then the method will
raise an error because a Task with newId != Task with id in db.
This commit fixes the compute method to call the _read method only on a
self with no NewIds to avoid this issue and correctly updates the cache
to get the name of the users assigned to a task in project sharing for
the portal user.
Fix found by Florian Damhaut <flda@odoo.com>
Co-authored-by Florian Damhaut <flda@odoo.com>
opw-2745857
closesodoo/odoo#84298
X-original-commit: f61c4f43365d38a955c497e022f0e8f18f50a6b2
Forward-port-of: #84189
Related: odoo/enterprise#24207
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, the portal user is assigned to the subtask if he
creates a subtask via the project sharing feature. We recently hides the
`Assign to me` button to those users.
This commit removes the `default_user_ids` in the context used when we
create a subtask in the project sharing feature to not assign the user
to that new subtask.
Related PR: #84006
X-original-commit: f3a241e97f80007f6d7ce2567dd22784cb35de26
Forward-port-of: #84189
Part-of: odoo/odoo#84298
This commit adds unit tests to check the access of portal user. That is,
we check if the readable fields are only available in read access and
writable fields are available for the edition of the task.
We also check if the other fields in task model raise a AccessError if
the portal user wants to access to one of them.
task-2633229
closes#77156
X-original-commit: 1e7185bcdd8913c006148466dec260b8f6d53c0b
* = hr_timesheet, sale_project, test_main_flows
Smaller changes:
- Projects created on the fly (through `name_create`) will now come with a
default `new` stage in order for them to not be empty.
- Removed task auto assign upon creation besides in FSM's 'My tasks' menu.
- Allow the reordering of projects without needing to group by
anything.
- Make `project.task`.`description` and `project.tags`.`name`
translatable.
- Disable the creation of records in the view when clicking on `Tasks
in recurrence` stat button.
- Track the planned date of the task in the chatter
- Disable the creation of records in the view when clicking on
'invoices' stat button and add the kanban view to that action.
- Make milestones completely available to regular project users.
- Remove the 'Documents' button in the project's kanban settings menu.
- Add kanban, pivot and graph views to the 'Hours Recorded' stat button
on projects
- Add the calendar view on the 'Hours Forecast' stat button on projects
- The 'Sales Orders' stat button on the `project.project`'s form view
will now display the amount of sales order linked to the whole
project. So the one linked to the project itself if it exists + all
the tasks. It will also open them, form view if 1 else list view.
- Fix a typo in the settings 'projets' => 'projects'
- The analytic account of the project will now be assigned to the
sales order when a task is created through the 'Create a task in an
existing project' option.
Changed the portal task view to include a sidebar similar to sales
orders, with a simple menu leading to different parts of the screen.
Changed the `project.task` 'rating' stat button:
- The icon will now represent the latest review.
- The action will directly lead to the record's form view if there is
only 1 rating.
- Make some fields readonly in the form view.
- Display the % of satisfaction instead of the number of ratings.
Reorder all stat buttons on the `project.task` form view in this order:
- Products, Worksheet, Sales Order(s), Invoices, Ratings, Hours
Forecast, Parent Task, Tasks in recurrence, Tickets, Quotations and
lastly Customer Preview
Make the status of the project editable directly through the kanban
view. A new widget has been added to handle that properly. When editing
the status through that means, a `project.update` will be created with
the current date and the appropriate status. In addition to that a new
status has been added (only on `project.task`, not `project.status`)
namely `to_define` in order to differentiate new and running projects.
Projects now start with the `to_define` status.
The `project.project`'s rating stat button has been changed in the
following ways:
- The icon will now change in function of the satisfaction percentage,
smile above 66%, meh between 33% and 66% and frown below 33%.
- The color will also change depending on the rate, smile is green, meh
is orange and frown is red.
- The ratings will now be in function of the last 30 days instead of
all time and the action will also filter on those 30 days.
- Change the action name from 'Rating' to 'Ratings'.
`project.project` ticket stat button:
- Will now open the form view when there is only one record.
- Added the activity view.
- Disable the creation of new records.
- Rename the action to 'Tickets'.
Closes: odoo/odoo#75269
See: odoo/enterprise#20334
Task ID: 2611006
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Both developments 6c4910a and 7563b44 have been introduced nearly
at the same time in the saas-14.5 version, but the later one is
introducing a side effect that breaks the project sharing feature.
Indeed, before there was one assignee per task (user_id), and now
we can assign several collaborators (user_ids).
As the read on a M2O is just calling the name_get method, it wasn't
an issue.
Now, as it implies to read the res.users (and the res.partner) model,
the assigned users were filtered according to a specific ir.rule
for the portal users:
<record id="res_partner_rule" model="ir.rule">
<field name="name">openerp.portal.res.partner</field>
<field name="model_id" ref="base.model_res_partner"/>
<field name="groups" eval="[(6,0,[ref('group_openerp_portal')])]"/>
<field name="domain_force">[('id','child_of',user.commercial_partner_id.id)]</field>
</record>
This commit creates a new compute non-stored field called
`portal_user_names` to display the name of all assignees in each task in
the project sharing feature. Thus, the portal user can see all assignees
via this char field. The `user_ids` field is removed in the views of
project sharing since the portal cannot see all assignees with this
field.
By doing this, a collaborator cannot edit the field to assign or unassign
himself to a task. To keep this behaviour, two buttons are added in the
form view of task. One called 'Assign To Me', the current collaborator
will be able to assign himself to the task when he will click on this
button. The other button called 'Unassign Me' is to allow the
collaborator to unassign himself to the task.
part of task-2633229
closesodoo/odoo#78538
X-original-commit: 3b5a657df086b54def0bc0bdae89c19c89cb39f5
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Co-authored-by: Xavier BOL (xbo) <xbo@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Adds personal stages to tasks.
Users assigned to tasks will be able to have their own pipeline to
handle their tasks independently of the project's pipeline.
The assignee field on Tasks has also been changed to a Many2many to
support multiple assignees on one task.
The same table is used to store those information, essentially a triplet
(task, user, stage), to ensure that:
1) personal stages only apply to tasks to which you are assigned to.
2) synchronizing to make sure that you don't have a personal stage for a
task on which you are not assigned anymore.
Alongside those changes, some minor changes have also been made:
- Modified the task's tree view.
- Renamed the Tasks menu to 'My Tasks'.
- The default view is now the kanban view for the 'My Tasks' action.
- project_id is not required anymore, tasks with no project are
considered 'private', those tasks are only visible to those that are
assigned to it.
- Added tracking of both user_ids and depend_on_ids in the chatter.
Closesodoo/odoo#74087
Task ID: 2398734
This reverts commit fc7778f8c512202dc3361d6b87be8c28b299c3c8 because of
a change in the spec.
The access mode are removed and replaced by this access mode for portal
user:
- read: the user goes to the classic portal view
- edit: the user is added as collaborator of the shared project and can
access to project sharing views.
To do this, the portal share is inherited by the project share wizard.
This new wizard can be open to share in readonly and open to share in
edit mode via 2 buttons in the form view of the shared project.
A new stat button is added to form view of project to see the
collaborators of this project. That is, the ones can access to the
project sharing views. The project manager will can remove or also add
new collaborators via the views in this stat button.
task-2379518
closes#73341
Xavier BOL (xbo)