In odoo at many places the filter items are having repeated strings eventhough the
fiter works differently , so find all the places where this happens and give
proper string to each filter..
When no stage has been defined for a project, the new issues are
set in an undefined stage(stage_id = False). Then these issues must
be counted.
opw:676985
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
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.
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.
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.
Removed unnecessary imports
Removed duplicated _order
Cleaned kanban state update in write to avoid useless loops. Indeed when
updating the stage the kanban state is reset, if the new stage is different
from the old stage. Now in every case the kanban state is reset. This is
already the case in issue and does not seem to frustrate users.
If an issue project is changed, depending if the destination project has
a set partner ("Customer") or not:
- if set, the project issue partner will be set accordingly
- otherway the potentially set partner will be conserved
Since 3fe06da if the project had not partner, the partner was unset
which is undesired.
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.
>
> This merge adds some basic data to notification emails headers. It contains the related
> record of the notification. This allows users to classify / perform action based on
> headers.
>
> Headers :
> - X-Odoo-Objects: list of records
> - X-Odoo-db-uuid: database uid
In task and issue, we had the parent project and the tags in the headers.
project.task: use an onchange to update date_start when changing user_id.
Indeed date_start is automatically updated in the create / write. Without
the onchange, this may lead to errors related to date_start being greater
then date_end.
project.issue: code in create and write now takes into account date_open
values given to the method and avoid erasing them.
In issue however the onchange is not added. Indeed the date_open and
date_closed fields are not visible in the view. They are automatically
computed and used to compute statistics.
When choosing use tasks / use issues, correctly update the project alias. Indeed
only the use issues checkbox had an onchange. This revision adds the onchange
on use tasks so that the method correctly computes the new alias destination model.
Also updated the _get_alias_models method to be more modular instead of hardcoding
values. Call super.
Coming from hr_recruitment, where kanban_state is displayed, but without the customization
Also, remove lingering options in view, and missing fields for project_issue
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
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.
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
- remove unnecessary copy() method from project/res_partner.py
- remove old methods on project.project
- progress is not used anymore on project.project
- use clickable statusbar for project states
- remove _resolve_project_id_from_context
- rename project.category becomes project.tag to be more explicit
- remove old methods on tasks
- issues: remove option fetchmail_issue
This fix sets the first sales team of the current user as the default sales
team if no other one is given.
For models: crm.lead, crm.phonecall, crm.claim, crm.helpdesk,
project.issue, sale.order, account.invoice
Existing methods are removed and new methods in sales team model
(crm.team) have to be called when needed.
closes#6438
opw-633562
to message_add_suggested_recipient; signature has been updated when migrating to the
new API, removing an argument that is now contained in self. However all addons were
not updated accordingly.
rap-odoo