The editor was updated to handle a TODO but the TODO comment was not
removed. Originally, I wanted this commit to handle all TODO comments
around that code but failed to find the time -> at least this fixes the
comments...
Part of https://github.com/odoo/odoo/pull/74941
Part-of: odoo/odoo#74941
`isOpen` is only written during mounted but it might happen that the discuss
record is not yet created when the component is mounted.
task-2632702
closesodoo/odoo#75655
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
PURPOSE
Allow to group records by many2many fields.
Use case: turn the user_id m2o field on project.task into a user_ids m2m field
in order to assign multiple collaborators on a task
SPECIFICATION
Add many2many fields to the 'list of groupable fields'.
When grouping a set of records by a many2many, records linked to multiple
records of the comodel will essentially be in multiple 'groups' (even though
those are not really 'groups' anymore).
There will also be a "null" group, for records that have an empty value of the
many2many, like "unassigned" records.
Example: grouping a project.task linked to 10 res.users by the user_ids
many2many field, the project.task will be 'rendered/considered/displayed' 10
times, once per res.users.
Kind of like if we grouped the m2m relation table instead.
When grouping by a m2m field:
- listview
editing an instance of a record also updates each other instance(if any)
- the same goes when scheduling an activity, etc.
disable deletion
- the risk here is that the user might expected that this will 'unlike'
the record from a specific record of the many2many field
disable archive/unarchive
- kanban
disable drag&drop between groups
disable deletion
disable archive/unarchive
- searchview
display many2many fields custom groupby dropdown
With this commit, we also support groupby many2many field in mockServer so that
test cases are written based on that.
task-2508608
closesodoo/odoo#74985
Related: odoo/enterprise#20192
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The value returned by the search_read in read_progress_bar when passing
a m2m field is a list of ids, which then read_progress_bar tries to use
in a dictionary, list is not a hashable type thus it crashes.
With this commit we convert the group_by_value from list to tuple,
which is hashable, if we're dealing with a many2many field.
task-2508608
Part-of: odoo/odoo#74985
Grouping by many2many has been added with PR odoo/odoo#68958 (commit f4f570c3d6b403512d8523c74acd34d485f46af1)
However the display names are not resolved resulting in the grouping
displaying the actual id of the records.
This also breaks some features such as `read_groups` which expect the
group by data to contain a tuple (id, x) instead of just the id, this
commit adds name resolving on many2many group bys.
Task ID: 2398734
Part-of: odoo/odoo#74985
Purpose:
=======
This commit adds the project sharing feature. This feature consists to
share the backend views about project.task to portal users.
About the access rights:
- The project manager can share a project with project sharing feature.
To do this, he need to give access to portal users that we want their access in project sharing views.
He can choose between 2 differents accesses:
1. **Readonly**: The use has access to the classic portal views (on which he can post messages, and have a readonly access rights to the related fields)
2. **Edit**: the portal with this access right will can edit some fields of `project.task` model.
The difference between the classic backend views and the project sharing
views is in the project sharing views, we list the fields that the user
can read/write, so the portal users can see only the fields in
our list.
Moreover, the actions and the contextual menu (actions dropdown) are not
available in the project sharing views and the stat buttons are visible
but the click on these buttons are disabled.
Implementation details:
======================
- add `allow_project_sharing` option in project form view.
- create the webclient and routes.
- create own qweb bundle.
- add project sharing views.
- use the session to define the action and active_id
- create public fields for project sharing: in this step, we lists all field
names of the `project.task` model that we want to display for the
portal user. Two lists are created, one for only readable field names
and the other one for the writable field names.
Moreover, two properties are defined in the `project.task` model to use the
both lists.
- use `access_token` and check model in project sharing route: in this
step we check if the model is `project.project` and the `access_token`
is the one set in the project since we have the id of the project in the
params url.
- protect ORM methods: to avoid the portal user has accessed to too much
fields that he can, we have to check if all asked fields are in
the readable fields, if all fields are available for these users than we do the
method, otherwise we raise an `AccessError` exception.
- allow only `GET` method to enter project_sharing routes: the
`/my/project/<int:project_id>/project_sharing` route must only be
called with a `GET` method because this route is only used to have the template
to render the project sharing webclient.
- redirect the link in one of the sharing wizards to project sharing views if the portal user has an access
to the shared project and if the shared project has the Project Sharing feature enabled.
- only load `project.task` views for project sharing.
- remove longpolling in the project sharing.
- disable click on avatar to open the chat with the user or open the hr.employee form because these features are not authorize in the project sharing.
- remove the contextual action menu in the project sharing views
- add the chatter in the `project.task` form for the portal user with at least 'comment' access.
This user could send message and see the public message like portal chatter.
- replace the basic portal views when the portal user selects project in `/my/projects` by the project sharing views if the `allow_project_sharing` is enabled for this project and if the portal user can access to the project sharing views of this project.
Why did we implement this feature in this way ?
====================================
We thought to create a `project.task.portal` model. This model had contained all fields that the portal user can read and edit (`readonly=True` if the portal user can just read the field).
We had 2 possibilities for this solution:
1. link this model with `project.task` either with inherits attribute in `project.task` or by creating a many2one field in the project.task.
The problem with this solution is with `inherits`, we just copy all fields in `project.task` and not method, so we need to duplicate methods used in both models. Moreover, with `inherits` possbility, we have to create all records even if the Project Sharing feature is not used. If we took the other possibility (that is, create the Many2one field in `project.task` model) asks to create records when the `allow_project_sharing=True` in a project and also unlink/archive records when the Project Sharing feature is disabled in a project. The process is harder each time, the user enables/disables the feature. That's why we didn't do this solution.
2. the new model contains a sql view and we use the related field to create/edit tasks in project sharing views.
We don't do this solution because it was a big change and increase the complexity. Moreover, if the sql view gives all tasks of shared projects, we could have a security issue because the portal user could have access to the tasks of shared project in which he didn't have any access.
Another solution that we thought before doing this feature was to create the kanban view in portal. We didn't do that because:
1. the render of this view will not be the same than the one in `/web`,
2. we didn't want to duplicate the kanban view,
3. we need to allow the portal to create/edit task.
task-2379518
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#73341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit fixes a behavior when we send a batch of mailings
with no recipients.
When there is no recipients passed down, each mailing should
use it's own recipients and not the recipients of the first mailing.
closesodoo/odoo#75652
X-original-commit: 88d74fde5ce1ec70a88679429fda02180ce7fa81
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, this route displayed the portal form view of the
project. This view does not seem useful for the external user and prefer
directly see the tasks of this project.
This commit replaces the portal form view of the project by the tasks
list containing in the project. Moreover, another route has been added
to allow the external user to go to the portal form view of the task
selected in ths list.
This route is called '/my/project/<project_id>/task/<task_id>'.
We decide to replace the content of the route because we want to allow
the public user to access to the tasks list of the project with the
access_token of the project. Also, with this same token, the public
could access to the form view of the selected task and send a message if
he needs.
task-2379518
closes#73341
Before this commit, the project manager could edit the collaborator
records. That is, he could change the shared project or the
collaborator.
This commit allows the user to only see or remove the collaborators for
a shared project. If the user wants to add some new collaborators, he
has to use the project share wizard.
task-2379518
closes#73341
Before this commit, the project sharing feature is enabled by default
when the Project app is installed but the user could never use the
feature and thus we add more access rights to portal user for nothing.
To avoid this, this commit removes by default all additional access
rights given by project sharing feature and adds this access rights only
when a collaborator is added.
If the user removes all collaborators for all projects then we need
to disable the feature. That is, we will remove the access rights and
ir.rule records added.
So, the feature will not really disable but we remove the additionnal
access rights and ir.rule records added with this feature.
task-2379518
closes#73341
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
The compute field for fleet_vehicle().account_move_ids can be using
self.id where self might be a recordset with more than one record.
opw-2630226
closesodoo/odoo#75541
X-original-commit: c5e14bee56d2f36499088e217e86df3be0fb0fb0
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
With this commit, it will check if the tax name is given by external method and take that name if any.
For example,
vals = {'rate': 5.2, 'name': 'Odoo New Tax'}
tax_template = self.env['account.tax'].search(domain, limit=1)
new_tax = tax_template.copy(default=vals)
Current Behavior:
new_tax.name => 'Odoo New Tax (Copy)'
Instead of 'Odoo New tax'
closesodoo/odoo#75406
X-original-commit: 10a5ecceead2f450822387c6f1f2d98f98317a15
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Be able to search origin and move origin in a notebook page to avoid
issue if the origin is too long (in case of multiple MO with semi
finished products)
opw-2625476
closesodoo/odoo#75144
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When a document (SO/MO) create a demand and this demand is directly
refill by an orderpoint, then write the source document that triggered
the orderpoint in addition in the origin field.
The purpose is to have an easy base tracking configuration even if
the priority and schedule date (and the final customer) could change
afterward (origin field still editable)
Part-of: odoo/odoo#75144
Usecase to reproduce:
- Enable multi steps manufacturing (pbm at least)
- Set a RR 0 0 on a component
- Confirm the MO
-> The scheduler is not run for the components
It happens because only the moves raw are confirm and not
the pickings from the procurement group (like in SO)
Part-of: odoo/odoo#75144
Rename `Debug Menu` => `Debug tools...`
Remove `Debug tools...` hotkey
The commands in the debug category need to have a search value
to be displayed.
Task-id: 2622240
Part-of: odoo/odoo#74933
This commit is a refactoring of the command palette. It aims to improve
its design and make it very easily configurable. For this, we added the
config props allowing the command palette to know what to display.
The config of a palette command is composed of:
- categoriesByNamespace?: list containing all categories according
to their namespace;
- emptyMessageByNamespace?: dictionary having for key a namespace and
for value the message to display if there is no choice available;
- footerTemplate?: template to display in the footer;
- namespace?: namespace to add in the search bar;
- placeholder?: placeholder of the searcher;
- providers: list containing all the providers generating the commands
to display;
The providers are the only information needed in the config. The rest of
the config is optional.
This commit also adds the possibility to open a custom command palette
using the command service. For this, you just have to call openPalette
and give it the required config.
If the command action returns a config, the command palette will
not be close and will use this new config.
Task-id: 2622240
Part-of: odoo/odoo#74933
Before this commit, the portal user could see archived tasks by filtering the
tasks with the search view.
This commit adds a condition in the domain of the `ir.rule` for this user
to allow him to see only the active tasks.
task-2379518
closes#73341
Before this commit, the user cannot remove all access rights for project
sharing feature of a project with allow_project_sharing enabled.
This commit checks if the user has made a change in the access rights if
yes then the 'Confirm Access' button appears otherwise only 'Send'
button appears.
task-2379518
closes#73341
Before this commit, the portal can archive tasks via the kanban views
This commit removes the buttons thanks to the `archivable` option set to
false.
task-2379518
closes#73341
Before this commit, the portal user could use the public orm methods to
get more information than he allowed.
This commit checks in the orm methods if the fields used in those
methods can be accessed by this user.
task-2379518
closes#73341
Before this commit, when we set `no_open` in list view for x2m record in
form view, the no_open is not take into account. Either the list is
editable and then the form dialog is no displayed and the user can edit
in the list or the list view is readonly and when the user clicks on a
row in this list view, the form view dialog appears.
This commit changes the condition in the `no_open` to force to set to true
when the no_open is set to true. So, when the no_open=True even if the
list view of x2m record is in readonly, the form view dialog is not
called and thus it will no longer appear in this case.
task-2379518
closes#73341
Before this commit, the portal user cannot create task in billable
project because he has no access rights to employee mappings model.
Indeed, this model is used to know the pricing type of the project and
also to search the default partner of the new task. If the user cannot
access we need to do it in sudo.
This commit adds a sudo to search correctly the default partner of the
task.
task-2379518
closes#73341
Before this commit, when we change the access right to the portal user
and this user is in task form view with chatter. He can send message
even we remove the access right.
This commit checks if the user has the access before sending the
message.
task-2379518
Before this commit, when the portal user can access to project sharing
and click on the shared link of the project. He is redirected to the
`/project_sharing/<int:project_id>` route. Since only the portal user
can access and no public users, we could directly redirect to the portal
route and display project sharing views.
This commit removes the `/project_sharing/<int:project_id>` route.
The main route will always be the `/my/project/<int:project_id>` and
we check if the user can access project before rendering.
If the user can access to the project via the shared link:
1. If he is a public user then we render the classic portal view.
2. If he is a portal user then
- we check if he is an access to project sharing, if yes then we
render project sharing views otherwise we display the classic
portal views.
task-2379518
closes#73341
Before this commit, the portal user has no access to uom.uom model.
Therefore, this user has an access error when we want to see task form
view.
This commit adds a sudo to use this method to correctly display the
label for the unit_amount of timesheets shown in the task form view.
task-2379518
closes#73341
Before this commit, the portal user cannot access to the task form view
since he does not have any access to `account.analytic.account` model.
This commit adds `compute_sudo=True` in field definition of
`analytic_account_active` to bypass the access rights in its compute
method.
task-2379518
closes#73341
Before this commit, the portal could not access to timesheets of the
task in project sharing views.
This commit adds the access to give him the read access to the
timesheets in the tasks of the shared project.
Moreover, this commit adds a `ir.rule` to limit the access to this
portal user and we keep the default values to True on all perms,
that way if someone modifies the ACL to give C/W/U permissions,
this rule will still give some protection.
task-2379518
closes#73341
Co-authored: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, when the portal user can access to project sharing
views, he can just read. If we just add ir.rule to allow the edition,
the portal could create/edit. We have to allow the project manager to
define the access rights of portal users when he want to share them a
project with the project sharing feature.
This commit adds 3 access modes portal users in project sharing views.
1. **Readonly**: the portal can only see the tasks in the different views.
2. **Comment**: the portal can use the chatter in task form view.
3. **Edit**: the portal user can create and edit tasks.
task-2379518
closes#73341
Co-Authored-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, the portal users can only see the tasks in the
project sharing views.
This commit allows these users can also create tasks and edit some
fields in task.
task-2379518
closes#73341
Before this commit, if we put an invisible in attrs of div tag for the
chatter, the attrs is not taken into account because when the chatter
is mounting this div is replaced.
This commit changes the class for the chatter in project sharing and
check if the div is visible before mounting the chatter.
task-2379518
closes#73341
Before this commit, the portal user can read all fields in the
`project.task` model.
This commit checks when the portal user wants to read task record(s) if
this user can see all fields given in parameters. When the portal user
edits or creates a task, we check if this user can edit fields and
create/edit the task based on his access rights and the ir.rules.
task-2379518
closes#73341
Co-Authored-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, when the user changes the task, the chatter is not
updated so we keep the messages of the previous task. Same thing when
the portal user wants to create a new task.
This commit updates the chatter to allow to fetch the messages when the
user changes the task and also disables the chatter when the user is
creating a new task.
task-2379518
closes#73341
Before this commit, if the portal user is a follower of the project he
can use the chatter of new tasks in the project sharing feature since
the follower of the project is automatically the follower of new tasks.
But if he is not a follower of the task (for instance, old task in the
project) then we have to check if the
access token is the one of the shared project to give the access to
the chatter.
This commit checks the `access_token` of the project when we are in the
project sharing form view to allow the portal user to use the chatter.
task-2379518
closes#73341
Co-authored: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, the chatter is not available in form view of project
sharing even for portal user. Since the portal views, we have a chatter
for the portal users, we need a chatter for those users in project
sharing.
This commit integrates the portal chatter in the form view for only the
portal users.
task-2379518
closes#73341
Before this commit, when the portal user is connected and selects a project
in the list when he is in `/my/projects` route, we redirect him in the
task list of this project.
This commit replaces the basic portal view by the project sharing views
if the Project Sharing feature is enabled for this project.
task-2379518
closes#73341
Before this commit, the user in the project sharing views can
Archive/Unarchive the record via the action menu. He can also click on
the share button in the action menu.
This commit removes the default action buttons defined in the action
menu for form and kanban views.
task-2379518
closes#73341
Before this commit, there is no options to disable the click on the
avatar to open the chat in `Many2OneAvatarUser` widget.
This commit adds an option called `no_open_chat` set by default to false
and this option allow to disable the click when it is true. This option
is useful for the project sharing views.
task-2379518
closes#73341
Before this commit, the longpolling is active in the project sharing
views but it is not necessary for these views, since the chat is
disabled and the goal of these views is to give access to external
users to `project.task` views.
This commit removes the files about the longpolling for the bundle used
for project sharing.
task-2379518
closes#73341
qsm-odoo