With this commit, all instances of errors being raised inside
`BaseModel.unlink` overrides are moved into methods decorated with
`api.ondelete` which is safer.
Change of several labels to increase consistency.
Adapt the size of certain images so that they are rendered without
modifying their quality.
Display the employee's profile image in the grid view to improve
the visual.
Add the kanban view to the All Timesheets menu.
Modify the Time Off configurations so that the projects displayed are
those of a company and that the tasks are adapted according to
the chosen project and vice versa.
Make the hr_timesheet and timesheet_grid module icon the same
for better consistency.
closesodoo/odoo#51808
Taskid: 2239802
Related: odoo/enterprise#10745
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The 'timesheet_generate' and 'timesheet_task_id' fields have been set as
stored-editable computed fields.
The condition to compute the timesheet_generat field has changed to be
coherent with the _check_timesheet_generate constraint.
Keep the timesheet_generate field without its default value (True) to avoid
raising a ValidationError through the _check_timesheet_generate constraint
before the timesheet_generate field has been computed.
* Wrong environment for project & task creation
On company creation, a leave project and task are created, but with the
wrong environment, potentially leading to inconsistent values in a
multi-company environment.
* Company creation in batch
Also fix the create override decorator to specify the create override
supports batch creation of companies.
closesodoo/odoo#51264
X-original-commit: e6bd644851819692eeddadaa50950efd0f83f6d9
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
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>
- Install project_timesheet_holidays
- Create a company with any user (except the SUPERUSER)
An AccessError is risen.
This is because the new project is created in the new company, but the
user is not in this company. The record rule `project_comp_rule`
prevents the constraint to be evaluated.
`sudo` seems the only solution here...
opw-2146153
closesodoo/odoo#41144
X-original-commit: a7d24cabafe1a9c71f9dbdb7cf3f129006250951
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
*: hr_timesheet
project_timesheet_holidays
account
Creation of analytic lines will be done in batches instead of creating single
record by iteration. This optimization is done in order to speed up the creation.
task-1971460
closesodoo/odoo#34481
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit provides some hook to extend values when a leaves
generates timesheets. It also use dates directly, rather than
converting them to string.
Closes#30867Closes#30872
When the many2xxx field relates to a model where company_id is required, set
this domain [('company_id','=',company_id.id)]
When the company_id field of the related model is not required, set this domain
['|',('company_id','=',company_id.id),('company_id','=',False)]
When setting the domain on a field which is in the treeview of a xxx2many field
evaluate against the company_id of the 'parent'.
Some constraints have been added on sereval models. Take a look at the complete
specification for more details.
TaskID: 2024446
Closes: #35266
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
It is currently impossible to create a company.
The reason being that the newly created company is
not yet in context `allowed_company_ids`.
Therefore, every consequent access to a record protected with
a multi company `ir.rule` fails for that company.
Here, the module automatically creates a project in that company
and later read that project to check a constraint.
The read raises an AccessError, hence the company is not created.
On the other hand, a user without project creation access rights
but erp manager could want to create a company. It should work
in that case too, as the project creation is transparent to the
user and the project is archived.
closesodoo/odoo#34920
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
In a multi company environment, some adjustment must be done:
- the company of an internal project of a company should be in that company
- the generate timesheet on holidays validation must be in the company the
task (or internal project)
The company should be correctly propagate to timesheets.
Task-1999686
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Currently, when a leave is validated, an `account.analytic.line`
is automatically created. However, the approver may not have
the access rights to do so.
This commit fixes the issues by using sudo to generate the line.
Purpose
=======
We need to use an international word to define holidays and leaves, rename everything into Time Off.
Employees needs a good dashboard and leaves summary
Specification
=============
1/ Add a new dashboard: https://balsamiq.cloud/sm5j0d/pg5w04r
Create a new dashboard with a calendar and a summary of all time off and time off request
2/ Rename leaves into Time Off everywhere
3/ Improve general usability
TaskID: 1916871
closesodoo/odoo#29634
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
Refactor resource calendar and resource mixin:
- add a required timezone field on models 'resource.calendar' and 'resource.resource';
- resource calendar attendances are now computed in the timezone of the resource
or the calendar;
- improve API of 'resource.calendar' and 'resource.mixin';
- avoid other modules from using the implementation methods of 'resource.calendar';
- refactor implementation of 'resource.calendar' to make it more efficient.
When validating a leaves from a leaves type "generate timesheet", some
timesheets are generated by the system. When refusing the holidays, we
want the timesheet to be deleted. It does not seem to be the case before
this commit.
Also, generated timesheet has a label containing 'False' if the holiday
description is not set.
Closes#22140
Purpose
=======
Have a clear distinction between leave and allocation requests instead of
using the same model to mix 2 different concepts.
Splitting the model will allow different business code to be run on each
model as allocations and leaves are not exactly the same thing; this
will add some code but simplify future improvements
Specification
=============
1/ Completely separate the models
Model hr.holidays has been split into leave.request and
leave.allocation.
2/ Make reporting working again by using an SQL view aggregating data
from leaves and allocations
A new report has been added in order to aggregate
datas from both allocations and requests. The views have been modified
accordingly.
The new settings model loads by default all settings. In the case of
non-admin user having the 'Settings' access rights this can lead to
access errors.
This commit deals with the multi-company issues on a standard
installation. If the admin is in Company A and the other user in Company
B, accessing the settings is pretty much impossible because of records
rules.
This fixes the master or demo data to avoid setting a company by
default. Note that it only fixes a standard installation: if the
settings are later customized, there is no guarantee that it will still
work.
Problematic fields:
`auth_signup_template_user_id`
`crm_default_team_id`
`leave_timesheet_task_id`
opw-801210
When using this module, the default behavior is to generate timesheet.
This timsheet is linked to a project and a task and there is a
constrain that verify that the task and project are set on model.
If another module (like l10n_fr_hr_payroll for example) tries to
create holidays.status without a project and task, it causes a
traceback.
This commit adds default values for these fields in order fullfill
the constrains.
Notice that the order of the imports in the __init__ is important
because the columns have to be created on the res.company before the
status is initialized.
These modifications are legit as the method is private and the user has the right to create a company.
This will create an internal project and a dedicated task.
A leave type now generate timesheet by default. So
the internal project/task are taken from the leave
type company (a default value for the company has
been added).
To allow the hr leave manager to select a project,
he should be alble to read the analytic account
(otherwise, crash when calling name_get).
Setting the default internal project/task is advanced,
so hidden in debug mode on timesheet config.
When refusing leave, we can not remove linked timesheet,
since they are attached to the leave.
We need to first detach it, then remove the timesheet
entries.
Also, add a test about the removal of linked timesheets.
This commit proposes to allow to automatically generate timesheet lines
when an employee is on leaves. Project and task used for timesheeting
is globally configured on the company. Holidays type choose whether to
generate timesheets or not and take the company default configuration.
When an HR officer validates a leave request, analytic lines will be
generated for each day off. The unit amount will be based on the working
calendar of the employee taking the leave. Generated timesheet lines are
attached to the project and task configured on the holidays type.
Configuring timesheet lines generation at holiday type level allows to
tune the use of leave requests. You may have for example "home working"
holiday type that should not generate timesheets while "legal leaves"
should.
Adrian Torres