If an issue is created without default stage, it is not counted in the
total of issues. However, a task without default stage is counted (see
commit 432c01c0).
Fixes#11398
opw-672380
On the project dashboard, a user needs to click exactly on the number or
on the label in order to open the issue list. If the user clicks outside
the text (but still inside the box), the project is open instead.
The reason is because the link is specifically defined on the
number/label. The fix defines the link on the box itself.
Fixes#11396
opw-672380
When using the mailgateway, the responsible of the newly created lead / applicant /
issue is explicitely set to False since the original mailgateway commit in 2010.
However this conflicts with some custom behavior that tries to set the responsible
on the same objects. Notably in recruitment the responsible is set to be the
recruitment responsible set on the job, if any.
In this commit we replace the explicit set of user_id=False to using a
default_user_id=False in the context. This way the admin or mailgateway user
will not be responsible of every new records. And this enables custom behavior
to find a responsible.
1/ An empty notebook was created in analytic and filled in account_budget
That way, we had a horizontal line while the module wasn't installed yet
2/ The fields use_task and use_issue displayed on the account.analytic.account
are just redundant information. The probable use case is to go on the project
select the issues management on it, and it will be activated on the related
analytic account. I don't think that anybody will come on the analytic account
to activate the issues. So we hide them in group_no_one
3/ On the analytic account form view, display the title label only in edit mode
Some computed fields have been added in v9 and are calling the method
_compute_day. This method accesses the project related to the issue
So a user portal is able to see his own issue, but cannot open the
form view as the prefetching is loading the fields. Hiding them in
the group base.group_user doesn't have any effect as the compute method
is called on the read. These information may have their importance to
the customer too.
We decided to compute these fields on superuser access rights.
Also the field project_id is displayed on the project_issue form view.
As this information is internal, we're hiding this also under the employee
group.
The access/follow/actions buttons on the notification email template
are sent only to employee. For this particular business model when
want all the users to receive them, as the portal users.
Christophe Simonis