- The HR staff may not be able to accept/refuse/cancel leaves if the
module `project_timesheet_holidays` is installed.
This is due to the commit c9da157149
introducing a manual check on the current user's group without
checking if the current environment is in superuser mode.
- Also fix the test verifying the access restriction, which meant to use
a different user, but did that with sudo(), obviously defeating
the fix. sudo is not used to switch user anymore, that `with_user`.
closesodoo/odoo#55274
X-original-commit: 75a166f1d115cc712bb39e7711d0fcb173732650
Related: odoo/enterprise#12149
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
The fields 'project_id' and 'user_id' have been converted to
stored-editable computed fields.
Convert the 'allow_timesheets' field.
Improvement of the _compute_task_id method to check the task_id field before using it.
Update hr_timesheet tests by removing calls to onchange methods because
now, compute methods are always called.
Get back the onchange on the 'project_id' to compute the task_id field due to a complex
bug found in sale_timesheet tests.
When we change the project on task, we change it also on
timesheet line if this line is not yet invoiced and if it
has no sale order line or the sale order line is the same
as sol of task.
closesodoo/odoo#45154
Taskid: 2169290
Related: odoo/enterprise#9471
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The 'allow_timesheet_timer' field should not have a default value as it is
computed according to the 'allow_timesheets' field value.
Some tests have been added to check the coherency between 'allow_timesheets'
and 'allow_timesheet_timer' fields, at project creation and update.
closesodoo/odoo#46692
Taskid: 2206820
Related: odoo/enterprise#8923
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Now that we have a new timer mixin that offers more possibilities
than what was currently implemented, we can reuse it in the timesheet
management module.
TaskID: 2149450
Purpose
=======
In Project, the configuration has to be done twice: in the settings of the
app and on each project.
During the onboarding, the user won't understand that a feature has to be
enabled at both places and will think that the system just doesn't work.
If the user enabled a feature, he most likely intends on using it for most
of his projects. Therefore, having to do a double configuration for each
new project is annoying.
By the way, sub-tasks is the only global feature (it can't be enabled or
disabled by project), so we are breaking it down by project to remain
consistent with the rest.
Specification
=============
1/ Enable subtasks per project
Before this commit, sub-tasks were a global feature (i.e. once enabled
they were enabled for all projects). This commit gives the ability to
enable/disable sub-tasks per project.
2/ Make project_id on planning required
3/ Change default rating status on new projects
4/ Default value for allow_subtasks
5/ Enable timesheets on existing projects
6/ Hide Total Hours if subtasks are disabled
7/ Create project in the company context.
Otherwise some records generation could use a default company which is not
the company for which we want to create a project.
8/ Default value for allow_forecast, is_fsm
9/ Change reference to timesheet product
10/ Fix tracback on industry_fsm_report.
Before this commit, there was a traceback when enabling "Worksheets"
(industry_fsm_report) after "Time and Material" (industry_fsm_sale).
11/ Convert some onchange method into computed editable stored fields
closesodoo/odoo#41218
Taskid: 2146474
Related: odoo/enterprise#6998
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
TaskID: 2088586
The low level access right is now "See my timesheets".
This access disallow to a user to view and manage the timesheets of others users.
When the visibility of a project is set on "Invited employees",
the users with the access rules : 'See my timesheet' and
'See all timesheets' can show the timesheets, if these users
follow the project.
Purpose
=======
Fields `customer` and `supplier` on `res.partner`
are mostly used in domains of many2x fields.
Those domains can confuse end users because they don't
see the partner they are looking for; and it's not obvious why.
Some identified problems:
1. It can lead to duplicated partners: the user does not find
the partner, so he creates a new one.
2. The user imports supplier contacts in the Contacts app, so they
don't get the `supplier` flag. Then the user wants to make a purchase order,
and cannot find the new suppliers in the list
3. A user removes the customer flag on a prospect, because they don't think
it's a customer yet - except now they can't make a quote for that customer...
Specification
=============
Remove the two mentioned fields.
Since fields `customer` and `supplier` have been removed, all partners
are now shown in many2one dropdowns.
But in some cases, not all partners are relevant or some are more likely
to be relevant than others. e.g. when creating a PO, top suppliers have a
higher priority than other partners.
So, adapt the places where those fields were used with the new mechanism to
display the searched the partners, according to the number purchase/sales
orders they made.
TaskID: 2031147
Co-authored-by: Yannick Tivisse <yti@odoo.com>
When used with a mutable default value, `dict.fromkeys()` builds a dict
where each key references the same value:
>>> r = {}.fromkeys(['foo', 'bar'], {})
>>> r
{'foo': {}, 'bar': {}}
>>> r['foo']['val'] = 1
>>> r
{'foo': {'val': 1}, 'bar': {'val': 1}}
Updating one key's value will change the value for all keys.
closesodoo/odoo#31659
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
Add some test to improve the test coverage
of hr_timesheet module. This commit brings
tests on time-tracked projects and their
deletion (and relation to their AA).
Impacted modules: hr_timesheet, sale_timesheet
When task is changing project or sale order line, we
don't want anymore to change the linked timesheet.
We now consider a timesheet is done in a specific time
at certain condition that does not have to change when
the environment is modified afterwards.
So, a timesheet linked to an analytic account for a
certain project on a task (and mybe linked to a SO line)
will still be linked to the same object if the task is
billed with another SO or move into a new project.
The idea is task actual configuration (project, AA, SO
line) are the default value at timesheet creation. As
consequences, timesheet from another project can be linked
to a task that does not belong to that project.
Project and task can be modified thougth the UI of timesheet
app. SO line and analytic account of a timesheet can not
be modified as they are more sensitive field (in a business
point of view), especially for invoiced timesheets.
This commit revert opw-1803811, as at that time the
'inheritS' between project and AA was still effective,
and there was only one billable type (task rate) for
task. The introduction of 'employee rate' billing type
will complicate timesheet transfert.
Tasks #34703
This commit removes the inheritS between account.analytic.account and
project.project. This means :
- When a project is created, an analytic account is not necessarily
genareted
- project has now its own name, company_id and partner_id fields
- an analytic account can be linked to several project
- project module does not depend anymore of analytic, but hr_timesheet
does.
This change implied
- an analytic account is required on project to timesheet on
its tasks. So, when checking 'allow_timsheets', if an AA is not
provided at project creation, an AA will be generated.
- to timesheet on project, an active AA is required. We don't want
timesheeting on project linked to unused AA to avoid bad analytic
entries.
This prepare the fact a sale order can create multiple project, sharing
the same analytic account (the one from the SO).
Others test classes extends the setup method, and break the
tests enviroment configuration. Extracting the global setup
in a common class is more modular and will make the enterprise
tests green again !
When we change the project of a task, we want the
related timesheets to be linked to the new project.
However, since a timesheet is an analytic line with
a project, a task with timesheet can not be without
project. In that case, an error is raise to prevent
this case.
opw-803811
Since partner is not required on analytic account, nor
on AAL, we may have lines related to different partner (a 'support'
project for instance, with task for different partner, the AAL will
thus also have different partner). This use case is not possible with
the field override in account.
This commit will allow to do cost analysis by partner in the same
analytic account.
Purpose
=======
This isn't useful now that project issues and tasks have been merged.
Specification
=============
Keep the label field, remove the checkbox
Arnaud Joset