| Age | Commit message (Collapse) | Author |
|---|
|
page
In multi-company configuration setup, Company A and Company B.
Have a project in Company A that I want to share with a user in
Company B. The user only has access to Company B.
Share using the project link and open using the user
Traceback error will raise.
Adding a default value to retrieve in case the filter option is used
but the user has no permissions on the records.
opw-2322236
closes odoo/odoo#57087
X-original-commit: bcb62e8f6e20bccc2f2350bdc1268c495b7103da
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
|
|
PURPOSE
Clean code and be and more performance oriented.
SPECIFICATIONS
Various portal pages hold references to archive_groups. It was a summary
of customer documents for portal, containing a count of all documents split
by model.
Currently its computation is not used. Indeed archive_groups is displayed
only in 'my_details' page that does not hold any document-based reference
or code call. Other calls to archive_groups are dead code as the result is
not used. Since 13.0 it is even not computed on standard pages to speedup
their load (as it was not used).
It is not used anymore and its computation and references can be removed
safely, especially with v14 in mind for which we want to remove dead code
to maintain.
Followup of odoo/odoo#55228
LINKS
Task ID-2329081
PR odoo/odoo#55800
PR #12368
Related: odoo/enterprise#12368
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
Before this commit, the time to compute all counters was making the rendering
of the portal page slow.
Now the count is done in rpc after the loading of the page.
Now you can decide which part you want to show on the portal, and only compute
for these one.
It is not because you have purchase installed for your internal process, that
it means that your supplier use your portal and it avoid the computation for
all end users.
We parallelize the counters in arbitrary 3 rpcs.
closes odoo/odoo#55999
Related: odoo/enterprise#12456
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
|
|
The archive groups feature allows the user to have fast access to
records of a given month, under its details information.
But since the details section isn't shown anymore on portal sub-pages,
the feature is computed for nothing on (most) pages.
Removing this computation avoids a read_group call on portal subpages
(multiple potential queries).
This commit disables the feature until a total removal in master.
my_details is only truthy on the /my/account portal page, where no
archive_groups is given anyway (and the value is set to True only in the
rendered tempate itself).
X-original-commit: 40c57fafdd5651a522891ab68affe38933ea5202
|
|
The record counts are only useful for the badges displayed in /my &
/my/home.
By avoiding those counts on subpages, we gain a lot of useless queries,
improving the loading speed of those sub-pages.
X-original-commit: 79c8384f1bcbcdede030e187008319a70c664571
|
|
- Rename the 'Use Rating on Project' feature into 'Customer Ratings'
- Rename the 'Set Email Template to Stages' link to 'Set a Rating Email Template on Stages'
- Add an optional list view for the Stages menu
- display warning if the rating_template_id field is set and if one of the selected project_ids doesn't have the rating_status field set to true
- Project form view revamp
- rename the '% on tasks' stat button into 'Customer Satisfaction'
- Remove the 'no option' for the rating frequency field because it is required
- project form : Add a 'Go to Website' stat button
- Project dashboard: remove the 'Customer Ratings' menu item in more
- Ratings page: the 'Last 30 days' filter include ratings from today
- remove the Appointment / Helpdesk Customer Satisfaction / Live Support menu items
TASK ID : 1251
|
|
If a visitor has access to a task through access_token, he should have
access to the task attachments. He already see the list of attachment
and their name, but since the task access_token is not propagated to the
attachment he doesn't have the rights to see them.
In this PR, we generate the attachments access_token and provide them to
the user that is viewing a task with an access_token.
opw-2125252
closes #41881
closes odoo/odoo#42121
X-original-commit: e7984c4968cde2019edca6c767d2acce2f7fe3f4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
on the portal:
- in Timesheets, when search something, the text of the search must remain displayed
- in Tasks, when search something, the text of the search must remain displayed
- in Purchase Orders, "Sort By" and "Filter By" selectors shouldn't change when going to next page
- in Timesheets, the "Group By" selector shouldn't change when going to next page
closes odoo/odoo#40278
Related: odoo/enterprise#6787
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
A group by stage on the portal would allow the customer to have an overview of his tasks' progress, which is especially useful in a multi-project setting.
- add a "Project" column
- rearrange columns in the order: Ref -> Task -> Project -> Stage
- add a group by stage for Tasks on the portal
- hide "Stage" column when group by stage is selected
- hide "Project" column when group by project is selected
- add a sort by project for Tasks on the portal
- when sort by Stage sub-sort by Project
- when sort by Project sub-sort by Stage
- add a 'Search in Project' for Tasks on the portal
- the "Group By" selector shouldn't change when going to next pages
|
|
PURPOSE
Rating model should be available only for internal users. External users
access them only through dedicated routes or controllers using sudo and/or
granting access through tokens. Therefore simplifying ACLs should be feasible.
SPECIFICATIONS
Remove access to rating.rating for public and portal users. Only employees
can access it, with full access given to system admins.
Update various functional flows to use sudo() and check that access is
verified before using sudo.
Impacted modules
* rating / mail: add groups on some rating related fields as only
internal users should access them now;
* rating / mail: set some statistics fields using compute_sudo as their
value should be accessible for external people even without access to
the underlying rating.rating records;
* project: makes some use of rating and has to be updated, notably for
the public rating page;
* website_{livechat, rating, slides}: add sudo in public routes as access
is already granted;
* website_slides: set statistics field using compute_sudo as their
value should be accessible for external people;
TASK ID 2053096
PR #36592
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
From now, you need to explicitely add sitemap=True if you want your controller
into the sitemap.
It's the default value, but if you forgot it, it will raise a Warning on runbot.
It will avoid wrong controller in sitemap and duplicate (empty) content.
From now, if your model contains a field website_id, the modelConverter for
sitemap will automatically add the domain:
"[('website_id', 'in', (False, current_website_id))]"
It avoid redundant declaration and ugly url in redirect/rewrite view.
Migration: need to remove it from url_from in website.rewrite
task-2065018
closes odoo/odoo#39427
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
|
|
preparation for cleaning of v13
task-2065018
closes odoo/odoo#39051
X-original-commit: 8a0fc6476c70a4126043de3b3efbd1096e41f968
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
|
|
|
|
The function _compute_parent_rating_percentage_satisfaction used the creation
date of the rating to compute the percentage.
However when a client give a new rating, it updates the old one.
As a result it doesn't give the recent satisfaction percentage,
but the satisfaction percentage of recently created tickets.
In other words recently angry clients from old projects would not appear.
Similarly this method is somewhat reimplemented directly in SQL in the rating
route, which happens to be in the project controller.
opw 1921486
closes odoo/odoo#30752
|
|
|
|
|
|
|
|
closes odoo/odoo#28678
|
|
If the selected project has no task (e.g. new project), still make a search.
The previous code was making a KeyError on the filterby as the read_group
returned no result.
Introduced at d5bc0e57cd9288dc7
As a portal, a user may have access to some projects (when set explicitly as
the customer on the project configuration).
Make this with a first search and add the other tasks also with the read_group
in case the user has access to some tasks but not the project.
Fixes #27457
closes odoo/odoo#27581
|
|
The search on project were done as sudo with a domain matching the
"project_task_rule_portal" rule. This commits remove the sudo call
and corresponding domains.
This replace lpe's fix b8fe404e, and user connected to portal to see
his tasks, avoiding an error during crawling tests:
Error use case:
User try to access a task list from /my/projects with a filter on a project.
The project filter does not exist in task list since the rules applied are for
portal user -> an error is raised
Now, project list on /my/projects and the filter available on /my/tasks should
be the same.
|
|
|
|
|
|
|
|
before this commit, on /my/tasks, in the filter dropdown, every project that had visibility = portal was displayed
regardless of whether the portal user was a follower or not
After this commit, we search project in a more clever manner
OPW 1878187
closes #26615
|
|
|
|
Before this commit, the method _document_check_access would succeed if it was called with a non-existing id.
Now it will raise a MissingError.
PR: none
Task: none
|
|
Purpose
=======
- Quickly share the url to someone else (a client, a colleague,...)
- Ensure that the recipient can access at least
the portal view of the shared record.
- Typically used when a client cannot retrieve the mail to access his order.
The share link can be used in this case.
Specifications
==============
For any object inheriting form portal.mixin:
- Add a button SHARE (not visible in edit mode)
- When clicking on this button, a popup opens with :
- A warning message for tasks and projects only (see below)
- the link (like in gmail) that can be copied
- Recipients
- mail composer (with preselected template) ==> see below
- button [Send Link] [Copy Link] Discard
- After sharing document, put internal note like
"Document shared to xyz,...." with template message
- Anyone with the link, even anonymous user (not logged in) can have access
to the document with the access token provided in the url.
Impacted models:
- account.invoice (Community)
- project.project (Community)
- project.task (Community)
- purchase.order (Community)
- sale.order (Community)
- helpdesk.ticket (Enterprise)
Warning messages and access rules:
Allowed :
- SO canceled or draft will be accessible with the link
with access_token
- If the customer account is B2B (signup not enabled), the recipient
will anyway see the document as the user specifically wants the
recipient to see the document.
Restrictions :
- For Project and Task, if the privacy is not public, then, there is a
contradiction between the access_token mechanism
and the privacy of the document.
- A warning message will be displayed in the share wizard to inform the
user if the document cannot be visible by the recipients and to
ask him to set the privacy to 'Visible by following customer'.
The send button will, in that case, be hidden.
- To avoid to block the share for a new project, default privacy value
is now set to 'Visible by followong customer'
Technical implementation
========================
- Move the access_token mechanism (field + methods + mail controller)
to the portal.mixin to be able to use it in a generic way for each object
inheriting the portal.mixin
- Generalise a part of the _*model*_get_page_view_values method
into a single one in portal
- Generalize the _*model*_check_access into the portal controller of the
portal module
- Remove the init_column + default value for the access_token
> old records have an access_token,
> new one won't but it will be generated on demand via the get_access_token
Done for performance reasons
- Add share button into action menu separately. + kanban view context menu
(except for task and project where button not in action menu but 'simple'
button for task and project because other modules already provide action
to send documents by email, which is not the case for project and task.)
- Add a sign_token used to authentify the recipient in the portal view chatter,
if any. The message will be posted as if the user was logged in.
- Set the _get_share_url as private for security reason
- Add a redirect parameter to _get_share_url to get
If false : The direct portal view url
If True : The redirect url (mail/view/?)
- Cleaning up unnecessary code
- Bug fix :
- Before, if user was not logged and record had partner_id,
if partner id was null, post message was done as admin.
Now, the post message is done as public user.
- If the user had an uid but had no access_token, he could be able
to gain the access token of the record.
check_access_rights was missing in the get_access_action.
Task ID : 30985
Closes #25629
|
|
|
|
|
|
With the portal user, go on /my/task/1
(obviously provided that this task doesn't belong to portal user)
Before this commit, there is a 500 error
After this commit, the exceptions are handled and throws a 403
OPW 1867795
closes #25951
|
|
Note: 1aacc962620982528a3dfc90d2c1dd0027359375 has been ignored and will
be forward-ported later
|
|
|
|
- Searches made on tickets using the portal aren't kept when changing page.
This commit makes sure the search is kept.
OPW-1857033
|
|
Remove some code that was kept for retro-compatibility
while merging task 1827950 in 11.0 (stable)
Task #1838048
PR #24425
|
|
|
|
The portal view for tasks previously listed all task of all projects
without grouping them. It was a problem, mainly when we want to make
the distinction on project label_tasks, to make the difference
between tasks, issues, ... Grouping task by project by default allows
to show the label_tasks before each project.
Grouping the tasks removes the possibility to define a primary
ordering. We want to be able to ungroup the tasks in some cases.
The implentation was done in the portalsearch bar adding
a group by option. The portal proposes two grouping options,
project (by default) and none (to keep strict ordering).
Task: #1827950
PR #23769
|
|
|
|
Odoo 11 comes with unified features for Project Tasks and Project
Issues. Specifically, issues were retro-fitted into tasks, and saw their
specific features added to the features of tasks.
During this refactoring, the portal controller for issues was superseded
by a unified portal controller for tasks, via
623ea432681a8a0861fec6db0194f3911429efb2
One case was lost in the process: portal visibility of
tasks/issues/things that are individually followed by customers, without
the customer following the project itself.
This is important for `transversal` projects, such as a "Helpdesk"
project common to all customers, where each customer only sees their own
issues.
This commit restores the feature, previously added to issues by
1cc8252a953ba6adeeb5dead2c82b336cd51c9db
Note: this clearly requires a proper regression test, to be added soon.
|
|
Displaying the rating of project is moved directly
in project module, since it does not depends on website.
User may want to display rating of its support project
even without website.
|
|
|
|
|
|
Making project depending on portal, makes website_project
useless. So move all feature from one module to the other.
|
