The odoo.addons.web.controllers.main python module have been splitted
over multiple files on the basis 1 controller = 1 file. In this work we
adapt all modules to use the new imports.
A non-exhaustive list of where stuff have been moved:
* main.Home --> home.Home
* main.Session --> session.Session
* main.WebClient --> webclient.WebClient
* main.clean_action --> action.clean_action
* main.ensure_db --> home.ensure_db
The complete list is accessible in odoo.addons.web.controllers.main.
closesodoo/odoo#87571
Related: odoo/enterprise#25746
Signed-off-by: Raphael Collet <rco@odoo.com>
test_task_postal_no_read` calls `assertEqual`, which internally
creates a savepoint which flushes pending computations.
This is done by flushing the transaction (through the cursor), which
in turn goes and flushes the models.
The environment being used to flush the models is arbitrary, picked
from the set of all living environments associated with the
transaction favoring those with a user set. This means the environment
used to perform the pending computation can be a lot more restrictive
than the operation used to initiate said computation, which may lead
to the computation being flushed not being *possible to perform*.
The issue here is that the test specifically involves a restricted
user ("Portal user", created for the occasion). Logging the set, at
the start of the test function there are 11 active environments
associated with the superuser (uid1) and one (1) environment
associated with that user, let's call it 19 (because that's the uid it
gets when running only that job).
On the runbot the envset seems to shuffle really well and about 2/10
of the runs will have the env(uid=19) in leading position[0], thus try
to flush the *creation of the task* with the portal user, which
specifically does not have access to tasks.
This works around the issue by flushing the task creation in the
`setUp`, however the underlying issues remain.
[0]: This also seems to require some load on the runbots, if the
runbots are pretty much unloaded (no pending builds)
reproduction is never achieved. It is not clear why load
would matter.
Local reproduction was not successful, even using a dump from the
runbot and inducing artificial load (via stress-ng).
closesodoo/odoo#87512
X-original-commit: fc08ff42ec8886f6258bde6586c4293b64c89456
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
Purpose
=======
Pictures from the digest emails are currently stored on the database
itself, meaning that if the database expires (e.g. after trial expires) all
pictures from previously sent emails won't be visible.
This is an issue since digest tips are meant as a marketing tool to bring
people to Odoo after trying a database.
Digest pictures are now taken from Odoo's server
(https://download.odoocdn.com/digests) so that the pictures will still
be visible after the database has expired.
From this commit onwards, it should not be allowed to change a digest
picture with the same name (to display a gif of a newer version), since
all databases with previous versions would receive pictures of a version
that does not correspond to theirs.
This also means that everyone client's Odoo server will contain pictures
that are never used. This could be fixed if Odoo stored them somewhere
else and didn't make them dependent from the git repository.
Task-2372195
closesodoo/odoo#87343
X-original-commit: 35157677a2a63a2559a72aff21e62e23a3c671a2
Related: odoo/enterprise#25654
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since #73341 copy_data is filtered to avoid leaking information to portal user.
Partically, it makes custom field not copiable.
Fix it by disabling the filter for internal users. This may lead to a problem
with hacky field `personal_stage_type_ids`. To avoid extra complexity in the
code, just mark it as `copy=False`. The latter change is kind of an improvement
from functional point of view, since using default personal stage seems to be a
better idea rather than copying the stage.
---
opw-2746922
closesodoo/odoo#87064
X-original-commit: 9947e82c5c25cde030aca43f7eb6fe1293300329
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
* hr_timesheet_{attendance}, project, rating, sale_timesheet
- removed the 'admin' group on the reporting menu items so that 'users' can
access these menus.
- 'timesheet / attendance' menu should only show if user has access for both
the attendance and timesheet.
- Project/User should access 'Task Analysis' report And Added rule for user.
- customer ratings: only show ratings which has access of their project/task.
- ratings: user should not able to edit ratings.
task-2467564
closesodoo/odoo#82634
Related: odoo/enterprise#23439
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Co-authored-by: Priyanka Kakadiya <pka@odoo.com>
Steps :
Create a recurrent task.
Delete it.
Run the cron "Create Recurring Tasks".
Issue :
IndexError: tuple index out of range.
Cause :
The cron calls a method which takes the last task of the recurrence
as a model. As there is no such task, an python error is thrown.
Fix :
Do not display the "Continue Recurrence" button when deleting the last
task of it.
opw-2743788
closesodoo/odoo#86309
X-original-commit: 9cfe0042dd6846cf8b52aebeb9dd6e7432b32322
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Currently, when making an import on the project. task and trying to enable the
'recurring_task' to True, the field is updated but a recurrence record is not
created.
Steps:
1. Create an import file of a new task record
2. Add 'recurring_task' field set to true
Technical Description:
The default value is not set when the file is imported. Such as repeat_interval,
repeat_unit etc. So we have called the default_get method.
task-2733539
closesodoo/odoo#86283
X-original-commit: e24ae464caa068fa0a9b87fd7573528973eb25a4
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit removes the `user_ids` fields in the project sharing views
because this field is replaced by the `portal_user_names` fields to
correctly display all the users assigned to a task.
This commit also removes some elements defined in the project sharing
views and they are unused anymore since they are invisible.
Part-of: odoo/odoo#77024
The purpose of the PR is, User/validation errors are sometimes not
correct in English and/or quite obscure and don't help the user
understand/solve the issue. so some copywriting should help make
the experience better.
task-2557805
closesodoo/odoo#80107
Related: odoo/enterprise#22402
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, when the user searches all the open tasks (the tasks
without a stage set or the tasks are in a stage where `fold` is False),
this search could be slow when a huge number of active tasks is in db
and most of that tasks is in a stage folded.
This commit stores the `is_closed` field to avoid doing a join into the
stage table to know if the stage linked to the stage is folded or not.
Because `is_closed` is a related of `stage_id.fold` and so we will avoid
doing a sql join to know if the task is a open one or not. To further
increase this search, an index is added too.
Closes#85513closesodoo/odoo#85968
Related: odoo/enterprise#24828
Related: odoo/enterprise#25055
X-original-commit: cf8bb93
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Co-authored-by: Laurent Stukkens (LTU) <ltu@odoo.com>
The purpose of this commit, is to make generic improvements in
project.
In this commit, following changes are made:
- add allocated hours field in project form and list view
- remaining hour widget in project kanban view displays allocated
hours (-) timesheeted hours on task
- hide progress bar in project list view if planned hours is zero
- hide task stages if user is set
- move company field below tags field
- project list view: rename 'Activities' to 'Next Activity'
task-2692856
closesodoo/odoo#82019
Related: odoo/upgrade#3149
Related: odoo/enterprise#23148
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Co-authored-by: Krina Oza <kro@odoo.com>
*crm, project
With owl2, the `el` of components is no longer available. It still
works in Odoo on LegacyComponent, which has been introduced to ease
the switch from owl1 to owl2, and we're now incrementally removing
it.
With this commit, the action scrolling helpers no longer rely on
component.el, meaning that views using them (through the hook
`useSetupAction`) no longer need to extend LegacyComponent.
More specifically, we move the action scrolling helpers from core/
to webclient/actions, as those helpers make no sense outside the
context of actions (and thus are unnecessary in the frontend).
Tests have been adapted as well.
closesodoo/odoo#85631
Related: odoo/enterprise#24902
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the translation is not done in lazy, so for each
stat button shown in the right side panel of the project update, a query
is done to find the correct translation based on the language of the
user. It means, the translation is costly and need to be done in lazy to
reduce the time for the translation of those stat buttons.
This commit uses the `_lt` to translate in lazy mode those stat
buttons. By doing that, the execution time is reduced from 750 ms to 250 ms.
X-original-commit: 95fe018
Part-of: odoo/odoo#85660
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Co-authored-by: Laurent Stukkens (LTU) <ltu@odoo.com>
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
This commit replaces Component by LegacyComponent when the component
uses removed features from owl 1 like getting its `el` or `trigger` an event.
It also adds `useService("rpc")` when component needs it.
closesodoo/odoo#85389
Related: odoo/enterprise#24745
Signed-off-by: Géry Debongnie <ged@odoo.com>
Steps :
Create a recurrent task.
Delete it.
Run the cron "Create Recurring Tasks".
Issue :
IndexError: tuple index out of range.
Cause :
The cron calls a method which takes the last task of the recurrence
as a model. As there is no such task, an python error is thrown.
Fix :
Do not display the "Continue Recurrence" button when deleting the last
task of it.
opw-2743788
closesodoo/odoo#85176
X-original-commit: 4f143131a1722e87b7dbb6b54a76b81ce2ba40cd
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, In the product form, when the selected uom is Hours and as Hours is the default uom, we display this conversion (1.0 Hours = 1.0 Hours) which is useless
Before this commit, Kanban is the only view available for projects. With this view, we can't select a batch of projects and display optional fields
Before this commit, Some wordings didn't have a significant meaning.
This commit hides uom conversion when selected and default uom are the same.
This commit adds the projects tree view.
This commit improves some wordings according to what was mentionned in the task.
task-2724965
closesodoo/odoo#82135
Related: odoo/enterprise#23206
Related: odoo/upgrade#3207
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Currently, a service can be configured to be invoiced on milestones.
This means that the user has to manually update the delivered quantity on the SO in order to invoice it.
We now also have the notion of milestones in the project module.
It would be nice to have a link in between the milestone and the corresponding SOL, so that the delivered quantity is automatically updated when the milestone is reached.
This would help the users save time, limit the risk of error and reduce the confusion of having unrelated milestones at two different places.
To this end, this commit adds a new "milestones" invoice policy that computes the delivered quantity of a SOL based on the milestones that have been reached, and renames the previous "milestones" policy into "manual".
Task-2558889
Closes https://github.com/odoo/odoo/pull/81684closesodoo/odoo#81684
Related: odoo/upgrade#3265
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, the `doc_count` field is defined into the kanban
view of `project.project` model but it is never used. Since it is
defined into the view, the compute of this field is unnecessary
called.
This commit removes `doc_count` field in the kanban view of project to
avoid computing the view since this field is never used.
closesodoo/odoo#85405
X-original-commit: 3c62c4aad5cecb9cc305925ca76ef24d375f5a09
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit display rating average percentage in project update right
side panel view's rating stat button instead of just displaying
rating_avg_percentange field's value.
task-2732325
closesodoo/odoo#82859
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The query added by 6c207ed1027d9b39eecd19886932b17f1a79dccd is not
optimal. Avoid using `LEFT JOIN` and `OR` by doing 2 queries and adding
their results.
From local tests, a `search_read` on `project.project` is about 4x faster:
2400ms -> 600ms.
closesodoo/odoo#85365
X-original-commit: 0235f2ded8ef6478ed36e2d8ba1c46acef5f1dab
Signed-off-by: Christophe Simonis <chs@odoo.com>
This commit is the 14th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
* `request.uid = x` => `request.update_env(user=x)`.
* `request.context = x` => `request.update_env(context=x)`.
* `request.context = dict(request.context, x=y)`
=> `request.update_context(x=y)`.
* `request.cr = None` => `request.cr.close()`.
* `http.mono_db()` => `request.db`.
* `http.dispatch_rpc()` => `service.dispatch_rpc()`.
* `@service.model.check` => `service.model.retrying()`.
* `request.endpoint`
=> `env['ir.http']._match(request.httprequest.path)[0].endpoint`.
* `request.routing_iteration `=> `removed`.
* `request.jsonrequest` => `request.dispatcher.jsonrequest`.
Note that `request.params` is now set much later in the process. If you
are in a situation where you values from the query string or the
http body you can use `request.get_http_params()`.
Note that using the new `request.future_response`, it is possible to
add headers and cookies on the response object before the response
object is initialized. Please note that headers/cookies saved on
the future response will NOT be injected in case of error.
PR: odoo#78857
Task: 2571224
Purpose is to try to have a single entry point when dealing with rating
values. Also fix incoherency introduced with odoo/odoo@32ba417549 where grades
are not coherent in all computation. This new computation seems better as
bad is now limited to <= 1 everywhere.
Task-2728564
Part-of: odoo/odoo#82792
Steps :
Install project and sale_project
Log in as portal > Tasks
Search bar > Dropdown > Search in All
Type anything and search
Issue :
Access Error : You cannot read sale_order_id.name, sale_order_id.invoice_ids.name,
sale_line_id.name, message_ids.body fields in task.
Cause :
We search in every field including those portal doesn't have access to.
Fix :
Add the domain of the rule of task to the search domain, so the search
only occurs on allowed fields.
opw-2762212
closesodoo/odoo#84934
X-original-commit: 7c2855e17a85af6609a705abe50e69720f9bad75
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Issue :
In the kanban view related to shared project with portal user,
the term 'assignee' is not translated in the portal user language.
With this commit, this term will be translated based on the user language.
opw-2746504
closesodoo/odoo#85063
X-original-commit: 0231e1b78a3b377153c9d2e097b9d4aad9bc3b0d
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Step to reproduce:
- Schedule activity on a project update
- Access the activity
Current Behaviour:
- On Project.update, we try to compute the info related to the project_update's project
due to the project update view showing information about the project.
In case of notification, we can show multiple project and thus no project_id can be
provided.
- Traceback
Behaviour after the PR:
- If there is no set project_id when opening the project update kanban view
We do not show the RightPanel related to the project and do not compute
related PR in enterprise odoo/enterprise#24427
opw-2755473
closesodoo/odoo#85060
X-original-commit: 9e30888195db0d01f06dffa9d59ae652fe6de5f0
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit there was no easy/clean way to extend the domain, searchbar sorting and filtering.
By adding it in subfunctions we can do clean extending of the domains/filters
closesodoo/odoo#84912
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit:
* rating_last_value takes non consumed ratings into account, which prevents
dissatisfied filter to work as expected.
After this commit:
* dissatisfied will be only based on rating_avg.
closesodoo/odoo#84821
X-original-commit: 65c87efd78ad93d76c63575300f5d28cfcb42b29
Signed-off-by: Xavier <xbo@odoo.com>
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit introduces some user experience improvements:
- Always display sale_line_id field whether partner_id is set or not.
- Don't restrict sale orders to the partner_id's one
- Set partner_id to the one of the SOL if partner_id is False
- Remove create option for fields 'user_ids'
- Display the kanban state in the kanban view even in fsm
Task 2585357
closesodoo/odoo#73531
Related: odoo/upgrade#3211
Related: odoo/enterprise#19812
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Co-authored-by: Priyanka Kakadiya <pka@odoo.com>
For the moment we cannot groupby an inherited field (which is therefore related) in a graph view, so it is counted as being non-stored.
Because in the `_normalize` function we do not process fields that are not stored, whereas like here
https://github.com/odoo/odoo/blob/d679cd0d8ba9a2420e81a42a698763e9be2327e1/addons/web/static/src/legacy/js /control_panel/groupby_menu.js#L45-L49.
Typically when a field has store=False but sortable=True it is inherited from a stored field, so it can be sortable
So we have to use `sortable` instead of `sort` to make it consistent.
opw-2733133
closesodoo/odoo#84612
X-original-commit: ce2a538e2988aef572171f783891cd6ee644ad14
Related: odoo/enterprise#24351
Signed-off-by: Achraf <abz@odoo.com>
Follow up of tasks 2379518 and 2633229 (#73341 and #77156).
Purpose
=======
The main goal is to allow the portal user to click on some stat button shown in the task form view in the project sharing feature. Those stat button will redirect to a portal view if the portal user has access to the document(s).
Then, some refactoring is made to easily use the existing code for one route to another one and review the code for the project sharing tour.
Finally, the `/my/project` and `/my/task` routes have been renamed to follow the same *naming* in the another routes. That is, those routes will be named `/my/projects` and `/my/tasks`.
## Details of the implementation
- Allow the portal user to click on the sale order stat button in task form view. This stat button will be clickable if the user has access to the sale order of the current task shown in the form view, otherwise the stat button will be invisible. If a portal user clicks on this button, then he will be redirect to `/my/orders/<id of the sale order>`.
- Allow to show the parent task from another project than the one shown in project sharing. If the portal user has access to the other project than there is no reason to not allow him to see the parent task.
- Rename the `/my/project` route into `/my/projects`.
- Rename the `/my/task` route into `/my/tasks`.
- Create hook methods to avoid duplicating code when we want to use this code to another route. It will be the case for a new route used in the project sharing feature.
- Create hook method in controller of account module to easily reuse the existing code for another route for project sharing feature.
- Refactor tour js for project sharing feature to remove the duplicating code.
- Revert the disable click on avatar. This changes was initially done for project sharing feature. However, this changes is made `web` module instead of the `project`. Since this changes is no longer used in project sharing feature and no used in backend code, the changes is reverted.
- Move the `invoice_count` field from `sale_project` module to `industry_fsm_sale` one because it seems this field is only used in that module and not anywhere before installing that module.
task-2648955
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#82379
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, the "Sub-tasks" has been added in the basic form
view of project.task in backend.
This commit adds this stat button in the project sharing form view to
have the same button than the one in backend.
task-2648955
Closes#82379
This reverts commit 0e1961b1dd because the
`no_open_chat` option is removed, this commit becomes useless, that's
why the commit is revert.
task-2633229
Closes#82379
Before this commit, we duplicate some steps of the tour js launched
with internal user to the tour js launched with portal user.
This commit avoid duplicating the steps. To do this, a list variable
stores the common steps of both tours and use this list in both tour
js to avoid duplicating the steps in both tour js.
task-2648955
Closes#82379
Before this commit, we recently change the content of this route. The
content is the list of tasks to the project instead of the form view of
the project. The problem is we don't have a route to manage the page in
the case where we have more than the value stored in `_items_per_page`.
This commit adds a route in the method for '/my/projects/:project_id'
route. The new route is called '/my/projects/:project_id/page/:page' to
manage the page of the tasks linked to the project.
task-2648955
Closes#82379
Before this commit, we recently added a new route in project portal
called '/my/projects/:project_id/tasks' to get the tasks related to the
project. The problem is most of the code in this route is duplicated
from the original route to see all tasks in portal view. That is, the
route called '/my/tasks'.
This commit refactors the code to have the common code in a common
method and changes the result in both routes to have the `values`
dictionary expected in those routes.
task-2648955
Closes#82379
Before this commit, when the current user is in the '/my/projects'
route and selects a project the route becomes '/my/project/<id of
project>'. There is no reason to change the route and then adding the id
of the project. In sales order route, we keep the route and we add the
id of the SO to see the portal form view of the SO selected.
This commit renames the route of project and task form view to keep the
same route and the same logic of SO and quotations routes for instance.
task-2648955
Closes#82379
Before this commit, the portal user can see the parent stat button in
project sharing form view of task if the parent is in the same project.
This button can be clicked and it redirects the user to the parent task
form view in the project sharing.
This commit improves this button and its visibility in project sharing
feature. The button is visible only if the current user has access to
the project of the parent task. That is the privacy visibility of the
project should be set to 'portal'. If the portal user has access to the
project of the parent task and he is not a collaborator of this project,
then the current user will be redirected to the classic portal view of
the parent task. If it is a collaborator then we display the parent task
in the project sharing feature.
task-2648955
Closes#82379
In big databases, the number of tags becomes rapidly huge. This makes
it very hard to find revelant tags. In practice, the same few tags are
usually used in a given project.
This commit:
- Limits the search of tags to the project's tags of the task as well
as to the tasks' tags of the task's project.
- Prevents creating case sensitive variants of existing tags.
- Reuse existing tags from other projects and other projects' tasks
when the user `creates` (or at least thinks creating as the
_name_search would not return the searched tag) a new tag in his project.
task-2735833
closesodoo/odoo#82925
Related: odoo/enterprise#23814
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Before this commit, when a form view was re-rendered (e.g. when
switching to "edit" or "readonly" modes, when using the pager...),
the chatter briefly disappeared and then reappeared, which produced
a flickering. This has been introduced by the adaptation of the JS
codebase to owl 2 [1]: when the form view had to be re-rendered,
we reused the DOM element containing the chatter in the new
rendering (done in memory), which was thus detached from the DOM.
That element was re-inserted into the DOM later on, alongside the
rest of the newly rendered elements.
This commit fixes the issue by using a specific "hook" element when
rendering the form view, and replacing that hook by the actual
(unchanged) chatter container element when the rendering is done
and the DOM is patched.
This commit also removes unnecessary overrides in project:
- _renderNode was dead code, classname "oe_project_sharing_chatter"
no longer exists in the codebase since [2]
- _makeChatterContainerTarget replicated what was originally
already done in the mail FormRenderer (for appearently no valid
reason), so obviously, that override wasn't synchronized with
this fix.
[1] edd79ff560
[2] a28cc6333aclosesodoo/odoo#84429
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Julien Castiaux