Grouping by stage_id on tree view in "project.task" when group_by_full
is defined on stage_id(to show all the stages in kanban view even if
they are empty), grouped by stage without summing all other the fields
such as remainig_hours.
Reason: The order defined in "project.task.type" was not strict and the
function _read_group_fill_results cannot group if the order defined by the
group_by_full(right_side) and the read_group(left_side) is not the same.
opw:724785
In 3041efb, it was introduced a partner_id reset when project_id is
False, but this causes you can't apply default values to partner_id
directly.
One use case where happens:
* Go to Sales > Customers.
* Select one customer.
* Click on the smart-button "Tasks".
* Create new task.
Before this commit, the customer where you come from is assigned.
After this, no partner is selected.
If you create a task when `default_project_id` is set, the stage_id
is initialized at the lowest sequence of the stages of the project,
which is normal. However, when you change the project of the task,
the stage_id was not correctly reset. If you save at this time, you
add the selected stage in the project.
Also, the stage_id was not correctly cleared if you remove the project.
If you create a task directly, the key `default_project_id` is not set
in the context. This key is used to compute the default stage of the
created task. It is done by creating a domain. Unfortunately, the
domain is always filled with `[('fold', '=', False)]` and thus it
always returns a result that makes no sense when `default_project_id`
is not set. Worse, if you actually create the task, the found stage
that was not in your project is now a part of it.
The fix is to return no result if the `default_project_id` is not set
in the context.
The onchange should have the signature with `ids` instead of `id` for a proper
guess.
Without this, the method can not be overriden with an api.multi (the return
result is a list of dictionnary which is not understood by the ORM as a proper
return format).
Fixes#12856
This is related to revision
c8aac116a6
`message_follower_ids` is a one2many field
on the thread. To copy them, you must
create new `mail.followers` records, and not
linking the followers of the project
being duplicated to the duplicated project.
Since duplicating a project copies the project
tasks, with the followers, the project followers must
remain as well.
This is done in the already overriden method
`copy` instead of simply adding `copy=True`
on the according one2many field, since this field
is defined on the inherited model
`mail.thread`, and to add `copy=True`, in the old api,
we would have to re-define the `message_follower_ids`
field within the `project.project`
model completely, making sure to copy all properties
opw-680313
Following commit 1dbccc8, there is no `user_id` field on the analytic
account anymore. However, a field `user_id` was added directly on the
project with commit 908f416.
opw-672333
Analytic accounts are inherited by project.project, and in some cases it is useful to have a link from the account to the project.
This is a usability-fix, not a code-fix
Commit bb1200adc7 introduced the automatic
addition of cc as followers of tasks and issues. However it seems to
automatically create partners if the address it not recognized. This
does not seem a good idea.
The onchange of the project field
removed the default partner loaded of the task
if there was no project set on the task, or if the
project was not associated to a specific partner.
There is no obvious reasons to do so,
and the revision 3fe06da634
introducing the regression doesn't explain why
it has been done. At first sight, there is no reason.
opw-657876
Since we're not duplicating work items when duplicating tasks during
project duplication, it doesn't make sense to duplicate the
likely correspondingly adjusted remaining hour.
Behave as if the planned hours had just been set/reset and set the
remaining hours of the new task to that instead.
fixes#8985
Also, we should be able to set a customer on a project, whatever the access rights,
for example, if we're managing services by using internal projects.
- Change the widget behavior from asynchronous to asynchronous, by adding 3 related fields
on the project.task model, which are the custom labels defined for the stage
- Instead of making a rpc call, we are taking directly the labels on the parent for the kanban view,
or on the view datarecord for the form view
- There are now 2 templates for the kanban view or the form view
- The development has been backported in the community version
- The options attribute has been removed on the project_view.xml file for the kanban_state field
Main addons updated :
- crm: Conversion and Won / Lost actions
- hr_holidays: Approve / Refuse for hr users / officers
- project: Assign / New (task and issues)
- forum, website_project_issue, website_portal_sale: go to the
website view
Major changes:
- New start and expiration dates
- Remove field Contract Status
- Simplified because use of sale_timesheet
Reason: complete rewrite of the Sale module.
Responsible: fp, dbo, nim
- hr, project, sales_team: no subscribe on create
For header records like sales steam, project, jobs and department, do not
subscribe the creator. Indeed those objects allow to automatically follow
child records (opportunities, tasks, issues, applicants). However those
records are often created by IT / technical / administrators that should
not be followers of all child records. Therefore the no subscribe key
is added in context.
- crm: new lead subtype
The 'new' stage is based on the sequence only, not the probability. Indeed
a new lead does not have a probability of 0; otherwise it is already lost.
crm:
- Move crm.lead.tag data to demo
- Rename Folded in Kanban view to Folded in Pipeline
hr_equipment:
- Rename Folded in Kanban View to Folded in Recruitment Pipe
hr_recruitment:
- Rename Folded in Kanban View to Folded in Recruitment Pipe
l10n_gr:
- Jump back to accounting dashboard after install
Project:
- Rename Folded in Kanban View to Folded in Tasks Pipeline
Sale_crm:
- Create a quote from an opportunity sets the right sales team automatically
Base:
- Move the tags
[REM] portal_project: move ALL the things
- move portal access rights from portal_project and website_project_issue to project and project_issue
- move portal menuitems back to their respective module
- remove public visibility of projects
- adapt demo data to have a 'Demo Portal' project
- add correct access rights for account.analytic.line for portal users
- small view tweak (do not display 'timesheet' tab if one can't see antyhing in it anyway)
- Add nocontent tip in kanban view of project documents and remove create button.
- Hide a lot of noisy fields from attachment form view in technical group.
- remove tags translatability
- add unique constraints
- res.partner.category is kept until we remove the parent_store test.
- hr remove tag parenthood
- hr remove unsed views and menu
concept of default / common stages.
However as the link between stages and projects is still a many2many
it is still possible to have shared columns. It is however not the
standard way of using stages.
Members were not used in project, except for the now removed faces library.
Statistics can still be computed based on task or issues responsibles
instead of adding all members of a project.
Indeed you could have members that did not actually work in the project
making it difficult to differentiate with followers. Now the concept
of members is removed. Followers is sufficient for communication.
code in resource and project.
This library was once used to perfom resource allocation: scheduling
tasks and things like that. However this feature cannot be accessed
through the interface since a long time.
The feature is now removed from the project code. The library has been
removed. Some code in resource used only in the project code
has also been removed, as well as a test linked to this code.
The new field will be the real date of assignation.
Don't use start_date for this purpose anymore.
Arranged fields in group to prevent view glitch
mentioned in task 19579.