avw/fp? request
58fc4e4409 changed various demo data,
including putting more "realistic" names in for the administrator and
demo users in demo mode. This is apparently inconvenient when actually
demo-ing Odoo as it's harder to see at a glance whether the current user
is the administrator or "regular" (demo) user of the db, though this
should have less impact since the userification of the admin
(2f7c03d9ca).
Specifications: improve menu organization, search filters and groupby, reorder
filters, update some field labels.
This commit is related to task #1875881 and PR #26938 .
In order to implement the next version of the dashboards in enterprise
we need to make some changes in community namely :
* Modify some search views (used in the dashboards)
* Remove the date/datetime filters from the search views as they are
duplicated with the time ranges
* Rename the menu items from Dashboard to Overview
*: crm,
hr_expense,
hr_recruitment,
point_of_sale,
project,
sale,
stock,
web_tour,
test_main_flows,
test_new_api
To sum up:
- Click on "Apps Menu" then the app item.
(previously: click on '+' then the app item).
- Click on navbar section menu item.
(previously: click on sidebar section menu item).
Defined as this, the label of the selection field were translated during code
import, when building the python model, not when a user access the field values
as it should (and is already the case thanks to the ORM).
Trying to translate a string when no user-context is available is not only
useless but may cause bug on services with multiple databases (e.g. a SaaS).
In a multi-worker environment, when the code is imported, the _ method will use
multiple scenarios to detect the language and get a cursor.
As we have no available cursor in the frame (method _get_cr from GettextAlias),
the fallback is made on the cursor of the request.
In a multi-worker environment, this could be a cursor linked to a database in
another language than English.
In such scenario, the selections would be translated in the language of the
other database instead of displaying it in English
opw-1881956
The group_by was passed from context from the action spawning a new view.
This meant that it could give a group_by a field that was not defined on the
destination view, causing a js traceback.
opw 1884035
When duplicating a task, we want the copy to have
the same sale order line then the original.
However, we duplicating a project, the tasks are
copied too. But, in that case, we don't want them
to be linked to any sale line, as the copy project
will not be.
This commit fixes that use case, and provides a test.
Task #1883640
* account, project, purchase, sale, website_crm_partner_assign
- Create a single template to be used for all doc's entry in order to
simplify maintenance
- Make the entire entry clickable using bts4 classes
- Fix an alignment issue between title and badge
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.
Following CDN expansion (d98b262398)
portal attachment links now go through the CDN, which is an issue for
restricted-access attachments e.g. attachments bound to specific objects
(such as support tickets).
Add an access token to the attachment links in the /my/task template.
Cf OPW-1882014 (fixed ad-hoc by editing the relevant view on odoo.com)
When switch to list view for tasks, we want them to be grouped
by stage. This was removed at 8169134715 without
justified reason, so this commit reset the previous behavior.
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
Prakash Prajapati