With project_issue installed, and when deleting an analytic account, a search
is done to check if there is linked issues. When the current user has no access on
the project.issue model, an error is raised. This check should be done as an admin.
Properly override `_track_template` similarly to what is done for
`project.task`, so the method can accept a recordset.
Co-authored by: Nicolas Martinelli <nim@odoo.com>
Closes#23466
opw-1823244
The depends for an issue inactivity_days expects a set create_date but
this may not be the case (when creating the record for example with the
field create_date in the form view).
opw-702532
- Use read_group to compute task_count of res.partner
for performance sake
- When creating a task/issue from partner form view,
the default partner will be the current one (event if
the use case is rare)
- Only display button when count is greater than 0
- Also avoid default 'My Tasks' filter when coming from
partner form view
ir.needaction_mixin is not used anymore by the webclient.
From 9.0, the concept has changed: this feature is now
available in mail module, with the mail.thread mixin,
and message_neeadction field.
Remove all code handeling needaction bullet and
counter on ir.ui.menu, knowing that since 9.0
webclient does not display the counter anymore.
This code was, thus, useless and some RPC calls
were done for nothing, and adapt accounting
reconcialiation widget.
Kanban state values are different from their visual display. When searching
on kanban state it is not easy to understand the link between the label
and the color. We now set the label as the color to ease matching and
searching. However in kanban view labels can be defined on the stage
itself. This way searching is done on the color while working with
tasks and issues in kanban is done using business meaning defined on
the stage.
As this button leads to a void form view without context it is not
really usefull. As creating new records is achieved using aliases
there is no real need for a New Task/Issue/Note button.
mail/new controller is kept for compatibility but should be removed
before v11.
the onchange changed the partners of the ticket when the ticket changed project
to the project's partner, but if the ticket already has a partner it shouldn't
change.
There is now a single method easier to inherit to add specific behavior
for the display of access button as well as actions buttons. All addons
using this mechanism are updated accordingly.
The dictionary `_group_by_full` is replaced by a field parameter `group_expand`
that is assigned to the method name. The API of the method has been simplified
as well:
@api.multi
def _read_group_stage_ids(self, domain, read_group_order=None, access_rights_uid=None):
# the stages are given by self.ids (wrong model);
# read_group_order is the order given to read_group() on self;
# return stages.name_get(), {stage.id: stage.fold)
_group_by_full = {'stage_id': _read_group_stage_ids}
is now written:
stage_id = fields.Many2one(..., group_expand='_read_group_stage_ids')
@api.model
def _read_group_stage_ids(self, stages, domain, order):
# stages is a recordset;
# order is the order to use on stages' model;
# return a recordset which is a superset of stages
* Number of emails should not take into account internal notifications
* Remove Channel and Tasks from issue report as those are not really
used anymore
* Remove New filter as it can be done through stage filtering instead
of using a not obvious heuristic based on stage sequence
[FIX] website_project: override get_access_action to redirect to my/tasks,projects
[FIX] project_issue: Don't send notif template to portal customers if no website
[FIX] website_project: Portal users can receive notif template
Move portal features (mainly ir.rule) from project_issue to
website_project_issue.
Remove backend menu item, issues should be accessed from the website_portal My
account page, the backend portal menuitem is removed.
Add the dependency on website_portal to display the issue count on projects.
Original authors: Vipul Bhatt, Florian Wintjens
Purpose:
For our internal project management, we would like to track the customer
satisfaction on the open projects. We send them an email every one or 2
weeks allowing them to give a feedback by clicking on one of 3
smileys: Happy, Average, Angry. They can also put a additional explanation.
We already have something similar which is working on livechat with a
unusable reporting, and on issues but unusable. Our project are managed by tasks.
Specification:
- On the project : Selection fields : (Periodical Rating or Rating on Stage)
+ Fields to choose the period if periodical
- On the stage : email_template_id field.
- IF :
---> Periodical : Send an email to all the customers for the tasks on this stage periodically
---> On Stage : Send an email to the customer's tasks when the task reaches the stage
- That way, it's impossible to send a satisfaction request both periodically and sequentially.
FP request
- Who is the customer : The customer on the task OR the customer on the related sales order
OR the customer on the projet OR nobody
- The last feedback is displayed on the task kanban card (Thumb up, down, or neutral)
- On the project kanban card, the customer satisfaction is displayed. This is the simple
mean of all the previous ratings.
Added a mail_template_field on project stage model (project.task.type). This
fields is used to automatically send an email when a task or issue comes in
this stage.
Recruitment code has been updated to use the mixin method.