This fulfills the goal of searching and fetching fields in a single SQL
query. We introduce the new method search_fetch() for that purpose.
Also introduce method fetch() to fetch some fields for a recordset if
they are not in cache yet.
The call graph is as follows:
search() calls search_fetch()
search_read() calls search_fetch() and _read_format()
read() calls fetch() and _read_format()
search_count() calls _search()
search_fetch() calls _search() and _fetch_query()
fetch() calls _search() and _fetch_query()
The methods _search() and _fetch_query() are usually the ones to
override to implement business-specific logic. The method _search()
returns a Query object to retrieve the records that satisfy the given
domain and are accessible for reading. The method _fetch_query() uses a
Query object to retrieve fields from the database and store them in
cache.
Also use search_fetch() to save one query in search_read() and the
reading of one2many fields.
Part-of: odoo/odoo#112126
This API is much more sensible for making subqueries. Specifically, one
can generate a subquery without the clauses LIMIT and ORDER BY.
Part-of: odoo/odoo#112126
This simplifies the use of subqueries by avoiding some costly default
order on the model or the idiotic order='id'. Method _flush_search()
has been adapted accordingly.
Part-of: odoo/odoo#112126
The parameter in search() is redundant with method search_count(), and
was making the calls less readable.
The method _search() is aimed at always returning a Query object. The
method can therefore never return an integer, hence the removal of the
parameter. This does not actually remove any functionality from the
method; counting result is simply given by using it differently.
Part-of: odoo/odoo#112126
Before this commit, when the user goes to project update of a project
with many tasks and some tasks are linked to some miletones of that
project the the `_compute_can_be_marked_as_done` could take more than
500ms depending on the tasks and miletones in the project (when the
project update of that project is loaded).
This commit fixes the performance by adding an index on `milestone_id`
field in `project.task` model.
Test case:
---------
The sql query made in that compute method took more than 600ms before
that commit.
With the index, the query takes less than 1ms.
X-original-commit: 47e02120b1aa5607a7fc528853629438cecf3e64
Part-of: odoo/odoo#114301
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Co-authored-by: SEINLET Nicolas <nse@odoo.com>
Rework of the hr.expense workflow so that:
- expenses paid by employee generate purchase.order
- expenses paid by company generate entry that look like payments
Main reason being that purchase.receipt are not active by default.
That makes the entry hard to find, holes in sequences, inconsitency
with payment states.
It also remove the refusal of expenses as this was dead / inaccessible code, only reports can be refused.
task-id: 3126550
[community](https://github.com/odoo/odoo/pull/110518)
[enterprise](https://github.com/odoo/enterprise/pull/36090)
closesodoo/odoo#110518
Related: odoo/upgrade#4266
Related: odoo/enterprise#36090
Signed-off-by: Laurent Smet <las@odoo.com>
In this commit:
- project tasks kanban view: if partner_is_company, we display partner_id
else commercial_partner_id -> this information is useless so we decided to
display partner_id in both cases.
- manager_id is not used in any view -> drop the field
- when creating a task by mail, email_from is set to the sender email then will
be changed depending on partner_id and parent_id, the field name is not significant
as it change and no more contain the original email sender, it's also a duplicated
information that can be got from partner / parent -> delete the field and create
a new partner if no one already exist with the same email.
- when project.analytic_account_id is changed, only tasks that have the same old
analytic_account_id will follow the name value -> we decided to change the behavior
and apply the new value for all tasks.
- project_analytic_account_id not used in any view and in only place in python
-> delete field
- project.project: partner_email, partner_phone are not used in any view ->
delete field
- project.task: partner_email not used -> delete field
- ancestor_id is no more used in any view or python reference as it's a complicated
field to understand by users -> remove ancestor_id from project.task and remove also
ancestor_task_id that is related it to it in timesheet context and replace it with
parent_task_id which is more simpler to understand by users.
task-3103701
closesodoo/odoo#110101
Related: odoo/enterprise#37246
Related: odoo/upgrade#4269
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The field email_from is a computed stored field. Let it compute for
the email_from instead of taking the one from the orginal task
closesodoo/odoo#113107
X-original-commit: 22079d6433d4025f7f92f260bb6f01ba836dcc34
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Bug
===
The unlink of the <mail.mail> in the CRON is problematic because we
accumulate a lot of records, and the CRON timeout.
In particular, when we sent a mailing, we receive the "opened" event
(blank image in the email), and so we need to update the mailing trace.
But, if we unlink the mail at the same time, it locked the mailing trace
table and we couldn't write the new value.
The reason for that is that before, the unlink took more queries, but
it was done one record at a time, so we could commit the change and
release the lock between each unlink.
Task-3179157
See odoo/odoo/pull/73271
closesodoo/odoo#112703
X-original-commit: 57ae1b9b8b61f5f4719a8a81e9d0d21fab58cfda
Related: odoo/enterprise#37069
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
The goal of this task is to ease the deletion/archiving of recurrent
tasks by giving the user the option to either continue
or stop the recurrence. The two main use-cases are:
\- You have a recurring task for a weekly meeting.
Next week, the user will be on time off. You are thus deleting the task.
However, you would still like tasks generated for the following meetings
and to keep track of the previous meetings.
\- You have a recurring task for a weekly meeting with an employee
that has just been fired. You are thus deleting the task and
you won't need this recurrence anymore.
(You may or may not want to keep track of the previous meetings.)
The main issue we are currently facing is that we need a task that acts
as a template for the recurrence to continue. This means that a user
cannot delete all of his tasks without breaking their recurrence.
Consequently, we will be using a "task template" for each recurrence,
which will only serve technical purposes and be invisible to the users.
When the recurrence is stopped, the task template is deleted.
This simplifies the technical and functional implementation as the user
won't be able to modify the template themselves.
\- Added task templates to recurrences in the data.
\- Deleted "all tasks" option form recurence update and changed "this
and following tasks" to "this and future tasks". Most of the time, the
user is going to update the most recent task, and it doesn't make
any functional sense to update past ones.
\- Same options for delete and archive.
\- No recurrent subtasks allowed anymore.
\- `date_deadline` is copied. We compute it by adding the delta between
the create date and the `date_deadline` of the template to the next
recurrence date.
\- Added filter to several view not to display task templates.
task-2937565
closesodoo/odoo#98088
Related: odoo/upgrade#4232
Related: odoo/enterprise#30416
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps:
Enable recurrence feature.
Go to Project > Office Design > Customer Review.
Enable recurrence on this task > Change month to year.
Issue:
Crash.
Cause:
`_get_next_recurring_dates` is called without a `repeat_month` arg.
Is is supposed to be a string which is going to be found in MONTHS keys.
Except it is False and so it is not in the list.
Fix:
If we don't receive it, deduce it from `date_start` arg.
closesodoo/odoo#112506
X-original-commit: 566c4904129dc7e81458871656d9b20b19b36246
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Audric Onockx (auon) <auon@odoo.com>
This commit add a mechanism to ensure that someone could never save
changes from an history that diverge (in case there is a partition in
the RTC network or a person A was disconnected while another person B
saved changes that were not transmitted to person A).
task-3002163
closesodoo/odoo#112099
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
On SO confirmation:
- If all of the following conditions are met,
set the end_date of the Subscription
as the repeat_until date of the Task:
The Product is recurrent and creates a Task,
The Task Template is recurrent,
The end_date field is set on the Subscription.
- If all of the following conditions are met,
apply the Subscription's recurrence to the Task's:
The Product is recurrent and creates a Task,
There is no Task Template on the Product.
- If the Subscription is closed, set the recurring_task
field of the related Task to false.
task-2868306
closesodoo/odoo#92696
Related: odoo/enterprise#27953
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Current behaviour:
You cannot set the Default Analytic Plan for projects in the settings.
Expected behaviour:
You should be able to set the default plan, like any other settings.
Steps to reproduce:
- Install Accounting, Project, (Timesheets if you want to test
project creation with an auto-created analytic account)
- Settings > Check Analytic Accounts
- Try to change the Default Plan in Settings > Project
- Upon saving, the change is lost
Reason for the problem:
The `analytic_plan_id` in the project's `res.config.settings` is
related to the same field on the `res.company` model.
The `analytic_plan_id` that is set on the company upon installing the
project module is a non-stored computed field, which makes a call to a
`_get_default` -> the field cannot be set. It will always return
the first default plan in the sequence.
Fix:
Since the field isn't stored (which would have worked if it was),
we use `ir.config_parameter` to write and read to it, per company.
In master we should just add a `store=True` and write a migration
for it?
Affected versions:
- 16.0
- saas-16.1
- master
opw-3127638
closesodoo/odoo#111635
X-original-commit: 11b0e2556ce824048bb4c760893b05e98537d171
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Add a constraint preventing the user from switching the project from company
if the partner doesn't belong to that company, and vice versa.
task-3126301
closesodoo/odoo#109464
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In a previous commit https://github.com/odoo/odoo/pull/98660,
we implemented `_search` method to search by `is_favorite`.
Unfortunately, this method looks for any order item starting with
'is_favorite' and so it could include 'is_favorite_gnagnagna'.
closesodoo/odoo#110745
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps:
- Install project app.
- Active Sub-tasks feature in config settings
- Create task with parent task
- Green the kanban state
- Modify the parent task
Issue:
The kanban state changes when we change the parent task in the task.
Fix:
We avoid the recomputing kanban state.
Why issue occurred:
When we change the parent task _compute_project_id is called and sets the project.
the _compute_kanban_state method depends on the project. So reset the kanban state.
task-3141855
closesodoo/odoo#110492
X-original-commit: 0393cffa71821ba32af8e9ba54225275647c4e70
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Change 'auto_delete_message' into 'auto_delete_keep_log' that has the inverse
meaning. Indeed it is unclear what 'auto_delete_message' really does. It is
used when automatically removing emails sent through mass mailing, to know
if message created through inherits are kept or not. Purpose of keeping them
is to have a log on the document. Deleting the message therefore removes the
log.
In this commit we change the meaning to something positive, keeping logs being
clearer when choosing which option to activate. Functional usage of the field
itself does not change with this commit.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
When a message is processed through the mail gateway, the partner should
never be set as the assignee of that task.
This commit allow to correctly let pass `{'default_user_ids': False}`
context from `message_new()` down to `create()`
closesodoo/odoo#110124
X-original-commit: 08e24d683bf19a77982a7ffba6c64b5fc6fdf85a
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
*=hr_timesheet,sale_project,sale_timesheet,spreadsheet_dashboard_hr_timesheet
The main goal of this PR is to minimize code duplication for the search and list views for tasks and projects.
Task search views
-----------------
The most important change was to merge the search views used in the task reports with the "normal" corresponding search view. The reporting search view should now be almost identical to the normal one in both project and fsm.
The `project.task`/`project.task.user` search views are now following this inheritance diagram:
```
┌─┐
┌─┤1├─┐
│ └─┘ │
│ │
┌▼┐ ┌▼┐
│2│ ┌─┤3├─┐
└─┘ │ └─┘ │
│ │
┌▼┐ ┌▼┐
┌──┤4│ │7├──┐
│ └┬┘ └┬┘ │
│ │ │ │
┌▼┐ ┌▼┐ ┌▼┐ ┌▼┐
│5│ │6│ │8│ │9│
└─┘ └─┘ └─┘ └─┘
```
1. `view_task_search_form_base`: Base search view containing all the fields/filters common to project, project sharing and fsm
2. `project_sharing_project_task_view_search`: Search view for project sharing.
3. `view_task_search_form_project_fsm_base`: Base search view containing all the fields/filters common to project and fsm (not project sharing).
4. `view_task_search_form_project_base`: Base search view for project only, with fields/filter common to the normal search view and the one used in reporting.
5. `view_task_search_form`: Search view for project.
6. `view_task_project_user_search`: Search view for the project report.
7. `project_task_view_search_fsm_base`: Base search view for fsm only, with fields/filter common to the normal search view and the one used in reporting.
8. `project_task_view_search_fsm`: Search view for fsm.
9. `report_project_task_user_fsm_view_search`: Search view for the project report.
With this organization, we can easily add a field to both fsm and project at once, and even to project sharing at the same time. Since the goal is to keep the reproting search views identical to the normal ones, it'll also add the field to both of them.
Task list views
---------------
Similarly to the search views, the task list views were also refactored to minimize code duplication, following this inheritance diagram:
```
┌─┐
┌─┤1├─┐
│ └─┘ │
│ │
┌▼┐ ┌▼┐
│2│ ┌─┤3├─┐
└─┘ │ └─┘ │
│ │
┌▼┐ ┌▼┐
│4│ │5│
└─┘ └─┘
```
1. `project_task_view_tree_main_base`: Base list view containing all the fields/filters common to project, project sharing and fsm.
2. `project_sharing_project_task_view_tree`: List view for project sharing.
3. `project_task_view_tree_base`: Base list view containing all the fields/filters common to project and fsm (not project sharing).
4. `view_task_tree2`: List view for project
5. `project_task_view_list_fsm`: List view for fsm.
Project views
-----------------
The search and list views for projects in fsm now inherit the ones from project, since our goal moving forward will be to keep those as similar as possible.
Other changes
-----------------
- Merged and removed many filters/fields from the task search views.
- Changed `total_hours_spent` and ` subtask_effective_hours` labels in `project.task` model to avoid changing them manually in many views.
- Renamed `state` into `kanban_state`, `hours_planned` into `planned_hours` and `hours_effective` into `effective_hours` in `report.project.task.user` to make it consistent with `project.task` (so we can keep the same views for both of those models).
- Moved the sale line filed in the "Settings" tab in the project form view (so that the `sale_line_employee_ids` field in "Invoicing" takes the full width).
---
Enterprise: https://github.com/odoo/enterprise/pull/34106
Upgrade: https://github.com/odoo/upgrade/pull/4216
Task-2746370
closesodoo/odoo#106015
Related: odoo/upgrade#4216
Related: odoo/enterprise#34106
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit when user creates a private task user
still able to customer and sol field which no use for
private task.
This commit hide customer and sol field for private task
and reset customer field when user make non private task
to private task.
task-3084850
Part-of: odoo/odoo#109281
Current behaviour:
When sending an email with an inlined image to an alias of a project,
the image is broken in the task description.
Expected behaviour:
The image should be rendered correctly.
Steps to reproduce:
- Install Project
- In Settings add a custom email server and set a domain alias
- Create a new Project and in it's settings create an email alias
- Send an email with an *inlined* image. (not attachment)\
- Image is not rendered correctly in the newly created task.
Reason for the problem:
Email with an embedded/inlined images are multipart, one is containing
the base64 encoded image and has a `content-id`, another one is the
html body that has an `<img/>` which source is a `cid` that references
the `content-id` of the encoded image. When parsing the email when
creating the task, we only take into account the `html` part of the email,
which becomes the `message.body` which is used to fill in the description.
Therefor we have an `<img src="cid:..."/>` that references nothing.
Fix:
Use the already parsed and sanitized `message.body` from the message's thread,
which converts the `content-ids` into relative links to web images.
We fill with that the description's body.
Affected versions:
- saas-15.2
- saas-15.3
- 16.0
- master
opw-3062444
closesodoo/odoo#109354
X-original-commit: 3c805400045f2ccc8ad4228eb5718af0e22a8027
Related: odoo/enterprise#35543
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Before this commit, when the user cannot write on a certain field
an error is occurred to notice the user, he cannot write on that field.
The problem is the `on` is never translated.
This commit fixes the issue to be sure the whole error message is
translated.
closesodoo/odoo#109288
X-original-commit: 5098c59cc6d1a853210f8c4f5340f0d4ee8dd883
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Description of the features in this PR:
add the date deadline to the order of tasks (sort priority)
add the day of the week (only the first 3 letters) for the recurrence message in recurrent tasks
display the name of the project in the action instead of 'Project Sharing'
By changing the sorting order of the Project.Task model
some indexations in the tests didn't point to the right tasks
Now each task that has a deadline will be placed in front of other tasks (except for the high priority task)
Task-3034635
closesodoo/odoo#105701
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Currently, when a db is loaded without demo data, or that a user has no
task assigned and no personnal stage, the view 'My tasks' is empty. The
purpose of this commit is to assign default personnal stage to a user in
these case to ease the understanding of new user of what the view can be
used for.
This commit :
- add default personnal stage to user the first time he clicks on the
'My tasks' menu if the user has no personnal stage and no task are assigned
to him.
task-3047496
closesodoo/odoo#105940
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Computing the recurrences of a task repeating every X months until a
certain date generates too much dates
Steps to reproduce:
1. Install Project
2. Go to Settings > Project > Tasks Management and enable Recurring
Tasks
3. Open any project in the Project app and create a new task then edit
it
4. Enable the Recurrent field of the task
5. In the Recurrence tab, edit:
- Repeat Every: 6 Months
- Until: End Date: one year from now
6. The recurrence message says there are 11 tasks but there should only
be 2
Solution:
Generate the recurrences until the `repeat_until` date is reached if the
`repeat_type` is 'until', otherwise generate as much recurrences as the
count
Also relax the constraint on the `repeat_day` and `repeat_until` to not
raise an error if `repeat_until` is the last day of the month
Problem:
The recurrence of a task with `repeat_unit` month and `repeat_interval`
different than 1 with a `repeat_type` until creates too much tasks,
exceeding the `repeat_until`
opw-3076593
closesodoo/odoo#107910
X-original-commit: 236b383fd9d1ad6a5d39d8c4232b49864ec19b37
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Steps to reproduce:
- activate "Recurring Tasks" option inside Project settings;
- go to "Field Service" app;
- create a task;
- check recurrence box;
- make the following configuration in the recurrence tab:
* Repeat Every 6 Months
* Repeat On Date of the Month 1
* Until End Date [your choice]
Issue:
The dates calculated for the recurrence are not correct.
Cause:
When we select an interval other than 1 for a frequency in months, we do not divide the number of months between the start and end date.
And therefore the loop that calculates the recurrence dates goes too far into the dates.
Solution:
Divide the number of months between the start date and the end date by the interval.
opw-3078084
closesodoo/odoo#107320
X-original-commit: 5d44d7d595dab866695945e5a6d2091ddd9df342
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Purpose of this commit to improve generic usage of project app.
So in this commit done the following changes:
- switch the id and the priority fields from place for task list view
- add a 'view sales order' button that should open the form view of the SO
linked to the SOL set on the milestone for milestone list view
- add a 'sales order' stat button that should open the form view of the SO
linked to the SOL set on the milestone for milestone form view
- add a 'done' option; represent it in purple in status field
- if there is only 1 assignee, display its name on the card instead of
1 assignee for project sharing kanban view
- add an 'all tasks' menu on the right of the 'my tasks' one
task-2917086
closesodoo/odoo#97669
Related: odoo/upgrade#3893
Related: odoo/enterprise#30195
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The goal of this revision is to add a group
`mail.group_mail_notification_type_inbox` which is granted
automatically when the user `notification_type` is set to `Inbox`
to be able to easily hide the filter `Unread messages` when
the user uses the `Email` notification type,
by simply adding `groups="mail.group_mail_notification_type_inbox"`
on the filter rather than overriding `_get_view` in every model.
The code overriding `_get_view` of `project.task`
to hide the filter "Unread messages" replaced
in this revision initially comes from
odoo/odoo@da868d28e2
> - In project.task search View:
> - the filter for unread messages should be visible only if the current user
> managing his notifications in Odoo
The above revision was part of the task 2844212
closesodoo/odoo#104328
Related: odoo/enterprise#33338
Related: odoo/upgrade#3996
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Before this commit:
When task project is changed in through the view the kanban_state remain the same
until the record is saved.
After this commit:
When changing project, kanban_state is changed to 'normal' direclty.
task-2849291
closesodoo/odoo#91174
Related: odoo/upgrade#3523
Related: odoo/enterprise#27287
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
After this commit:
- When duplicating project or task, assignment notifications and emails on stages are not sent
task-2849291
Part-of: odoo/odoo#91174
Before this commit:
- Task followers are not copied when creating subtasks
After this commit:
- Created subtasks have the same followers as their parent task with the same subtype_ids
task-2849291
Part-of: odoo/odoo#91174
Purpose of the commit is to do the generic improvements for project app.
So in this commit did the following changes:
- add the 'creation date', 'last stage update', 'SOL', 'my deadline' fields in
project task list view.
- add the 'my deadline', 'next activity' fields in project list view.
- crop the label of the stage after x characters in task portal form view.
- remove the 'collaborators' stat button from project update right-side panel.
- renamed sold->sales, services->sales order items, effective->delivered,
remove the totals, include non-service SOLs, increase the size of the SOL
column
task-2928100
closesodoo/odoo#97870
Related: odoo/enterprise#30268
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, when the user uses the `Late Milestones`
filter in the project views, all the projects in the views
are used, but some projects could have the feature disabled
and so those ones should be ignored in the filtered.
This commit filters the projects to only apply the filter
on those projects and not also the ones without the feature
enabled.
task-3033041
closesodoo/odoo#105709
X-original-commit: e8ee1e370ec3c6b4bc13d0d5da6b242af1e9b9c3
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit introduces the following improvements:
- In `My Tasks` list view: the personal stage is displayed instead of the stage for private tasks
- When copying a stage, the new stage name is appended with `(copy)`
- A default filter 'open task' is added in the subtask notebook search
- A default filter on the project is set on the search of the `parent_id` task field
task-3024152
closesodoo/odoo#103318
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, some error messages and others messages are
not translated.
This commit uses the translation function to be able to translate
those messages.
task-3006627
closesodoo/odoo#105192
X-original-commit: 85ef44cd66474bf5dcda4d7478d566e462d1a550
Related: odoo/enterprise#33717
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, when we create a new task in project gantt
view, the default current user is assigned to the task instead of
corresponding user.
So in this commit, assign the default user along with current user.
task-2920824
closesodoo/odoo#104967
X-original-commit: ab0e072fda7c2dff4ee7916496edfb6da11019ff
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit:
Let's consider project P1 having no stages.
Let's consider project P2 having Stage 1, Stage 2
When importing tasks via csv file:
- Task 1 for project P1 and Stage 1
- Task 2 for project P1 and Stage 2
Stage 1 and Stage 2 are still assigned only to project P1.
After this commit:
Stage 1 and Stage 2 are now assigned to P1 and P2.
Task-2996393
closesodoo/odoo#103819
X-original-commit: 2e6a7741dd2c993daa1b1aafe4ebd422cd57235c
Signed-off-by: Xavier <xbo@odoo.com>
Before this commit, when the domain used in `read_group` and `search` to
check if the portal user can access to the fields used in the domain
does not take into account the `TRUE_LEAF` (that is, `(1, '=', 1)`) and
`FALSE_LEAF` (that is, `(0, '=', 1)`). In other words, when the
`TRUE_LEAF` or `FALSE_LEAF` is in the domain, an access error is raised
saying the field name `1` or `0` cannot be accessible by the portal user.
This commit allows to add `TRUE_LEAF` and `FALSE_LEAF` in the domain to
avoid having an access error because of that.
close#103214closesodoo/odoo#103465
X-original-commit: 953033e1ab20a01918dae7ca495654cddef14af3
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
This commit remove tooltip from stage_id field of project model
from project app.
task-2999323
X-original-commit: 1e81116ea28de33ac54b99601ef5dd6048cef378
Part-of: odoo/odoo#103032
Before this commit, when we go to a Task. Click on the Tags field
> Search More. Group by Projects.
We get a list of projects groups. Click on them and they go from
(x) to (0) due to invalid group result from read_group without
valid domain same as search_read.
So in this commit, override the read_group method to pass the valid
domain same as search_read.
task-2959382
closesodoo/odoo#102236
X-original-commit: f9e9964c7138485ba328ce5cd4c4c8905c392adc
Signed-off-by: Xavier <xbo@odoo.com>
Steps :
- When the user is subscribed to the `Stage changed` subtype
but not `Task in progress` and on change of stage, the users only
subscribed to stage changed will not receive stage changed notification.
Cause :
- When the stage is changed it will also change the kanban_state to
in progress and due to that, it will track the kanban_state from
_track_subtype, and the user who subscribed only stage_changed will not
get notified.
Fix :
- So in this commit, prioritize the stage_id changed notification so that
when the stage_id is changed we use that one, and the in-progress won't
be triggered, but when we change the kanban state back to progress it
will be triggered. As in progress is implicit when changing the stage_id.
task-2818058
closesodoo/odoo#102172
X-original-commit: 4d952d679629a4a225ff208a6d018e11f14bf47e
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Steps to reproduce:
- have a project with a stage having the user_id set to Mitchell Admin (in this scenario you would have to add the field in the view)
- create a task in this stage
- log in with Marc Demo
- Try to open the project
Issue:
There will be an access error
Cause:
The domain allows to fetch all tasks from a project; even those from a prohibited stage
Solution:
- As in d4252825f5, we'll restrict the domain and "hide task stages if user is set".
- Prevent the user to create/modify a record to it with with a `user_id` and `project_ids`
opw-2917631
closesodoo/odoo#101965
X-original-commit: fdaef9276b89e2170128e205a4b7fd0b8defc2b1
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
Purpose
=======
To be able to customize the working flow on the task, based on their
project, we add a properties field on tasks, whose definition is stored
on their project.
Task-2965523
X-original-commit: 2f244769cbb1512875ae197aa8adc3efd34fd54b
Part-of: odoo/odoo#101487
The goal of this task is to review the copywriting of the tooltips
because some of them are not correct in English and others are not
valid anymore. This is also a good opportunity to make an inventory
of the tooltips we have and to add some that could be missing.
task-2862283
closesodoo/odoo#93261
Related: odoo/enterprise#28225
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The goal of this commit is to get rid of the analytic tags as they were confusing, serving tag purposes as well as distribution on analytic accounts.
Everywhere analytic tags were used as a distribution have been replaced with a new widget that will dispatch distribution on analytic accounts. If there was an analytic account field next to the tags, it has been included in the distribution.
Analytic tags that were used simply as information tags have been removed.
To fill the new widget, there are now 2 kind of rules that will help fill and prefill it.
The first are applicability: previous groups have been removed, and have by replaced by plans. Each account is required to have a plan. These plans define when they are available in the widget: a default applicability per plan and applicability lines that can specify rules following the context of the widget.
The second one are distribution models, that will replace previous default rules but follow the same principles. The accounts (and so the plans) that will be given by the distribution model can override the applicability rules from before.
closesodoo/odoo#98914
Related: odoo/upgrade#3885
Related: odoo/enterprise#30743
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Habib (ayh) <ayh@odoo.com>
Purpose of this PR to improve generic usage of project app.
So, in this PR done following changes:
- In project.project form view :
- Divided settings into sections
- In project.update.search.view :
- Added author, description and status in quick search
- Added ancestor task in group by and replaced parent task with ancestor task
in search view
- In project.task search View:
- the filter for unread messages should be visible only if the current user
managing his notifications in Odoo
- Added my private task filter
- In project_task_view_graph
- Added a default project > stages group.
- In project.task form view:
- If stage is_closed added decoration-muted
- Replace/Add parent task with ancestor task' in group by and quick search
- analytic-tags set on project should be automatically applied to it's tasks
task-2844212
Part-of: odoo/odoo#93676
Raphael Collet