The fix done in 3b966c2f21 remove the `('company_id', '=', company_id)` in the domain of
task_id field defined in account.analytic.line in hr_timesheet, but that tuple
is reintroduced in `project_timesheet_holidays`.
This commit also removes that tuple to be sure we will no longer have that
tuple used in the domain of task_id field for timesheets.
To reproduce the issue, follow these steps:
1. Install project_timesheet_holidays module.
2. From the settings menu, create a new company.
3. enter in multi-company mode by keeping the current one as active and
check the other company in companies switcher.
3. Create a project using the newly created company(e.g. New Company) and add
a task to it.
4. Open the Timesheet application and create a new timesheet.
5. In the timesheet, select the project created in step 3, and observe that the
dropdown for tasks does not display any task.
Current behavior:
----------------
The user cannot select a task in another company than the current one.
Expected behavior:
-----------------
The user should be able to select the task in the another company if he
is in multi-company mode.
task-3323027
closesodoo/odoo#131870
X-original-commit: d630711e795e7eddeb7b0ec47920f288920aedc6
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
_*: hr_timesheet,sale_project,sale_timesheet
Generally, you don't want subtasks to be displayed at the same level
as their parent tasks. You want to consider the subtasks as part of
their parent's project, but don't want to see them directly in this
project. Rather, you want them to be accessible only via their parent.
(There are exceptions to that and we want to stay flexible.)
First solution that comes to mind is to have `project_id` set to False
for the latter tasks, but then how to get the value of the fields that
are related to the project?
So, second solution would be to have a field `project_root_id`,
which would be the project of the parent, or the grand-parent, etc.
The issue now is that we have to fields "project", and it isn't obvious
when to use one or the other.
The most simple way to answer this need is to keep one field "project",
that will always be set for (non-private) tasks,
and create a boolean field : `display_in_project`.
But we want it to be technical (no checkbox in the view).
So, when the user unsets the project on a subtask, the view will act
as if the project was unset, but in the back-end,
we'll set `display_in_project` to False and set `project_id` back.
The fact that all tasks have a project allows us to know if action x
can be perform on this task t, dependind on t.project_id.allow_x.
task-3367246
closesodoo/odoo#128281
Related: odoo/enterprise#43996
Related: odoo/upgrade#4930
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
As of this commit, only confirmed leaves will be considered when computing the
current leave or absence of an employee. Additionally, a bug in the is_absent
search implementation was fixed: before this commit, the same results were
returned for absent and non-absent searches.
opw-2877328
closesodoo/odoo#124968
X-original-commit: 28ccbbab07a0c25570ca9b940428b8e541d262d7
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Allow timesheeting on sub-tasks with no project_id set.
Instead, refer to the project_id set on its parent_id, and so on,
recursively.
task-3336215
X-original-commit: d794e41619a36a8c9ad1e77a816e57051207cdcf
Part-of: odoo/odoo#124563
Before this commit when user create a global without calendar then
it'll not create any timesheets for any employee but global leave
without calendar is taken as leave global leave for all calendar
in that company's calendar and should create timesheet for all
calendars employee in company.
This commit create timesheets for all calendars employee in that
company if global leave does not have specific calendar set on it.
task-2969791
Part-of: odoo/odoo#100141
With this commit, we allow _timesheet_preprocess to accept a list of
dict of values instead of dict of values.
This represents an important gain in performance.
With 6 projects, 17 tasks/project, 10 timsheet vals/task = 1020 'vals':
Queries : reduced from 110 to 7.
Time : divided by ≃2.5.
task-3030942
closesodoo/odoo#103458
Related: odoo/enterprise#32967
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
-steps to reproduce:
do a search in project.task on is_timeoff_task when no
timesheet_task_id is defined on any hr.leave_type.
This will trigger the _search_is_timeoff_task method
-before this commit:
crash when no leave_type with timesheet_task_id is found
-after this commit:
creation of an empty list as expected
opw-3086486
closesodoo/odoo#110091
X-original-commit: b98949b1cb85514ee5a56ff1a5860591c10b0994
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
_* = project_timesheet_holidays
Before this commit checking validation for creating and writing
on timesheet done in create and write method which makes
customization difficult for user.
So, in this commit check validation for creating and writing on
timesheet done in separate method _check_can_create and
_check_can_write respectively for timesheet.
task-2928942
closesodoo/odoo#100943
Related: odoo/enterprise#31689
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
_* = project_timesheet_holidays
Currently, if the timesheet is associated with timeoff and it is deleted, a
user error occurs.
In this commit, RedirectWarning will appear instead of user error, so it can be
redirected to the timeoff linked to the timesheet.
task-2888607
Part-of: odoo/odoo#96359
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-2860991
closesodoo/odoo#102179
X-original-commit: 5e4cf8f9f6a4372f45aa04a5965f8073bb4ea68a
Related: odoo/enterprise#32298
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Co-authored-by: Mahendra Barad <mba@odoo.com>, Prakash Prajapati <ppr@odoo.com>
Issue:
When creating time off timesheet from the timesheet app,the newly
created timesheet is connected to a leave request while it shouldn't
be linked to any leave request and in consequence you can only delete
this new timesheet by deleting the leave request.
Explanation:
To create the new timesheet timesheet_grid makes a copy of another
timesheet on the same line and that makes that the holiday_id (used
to link timesheet and leave request) is also copied.
Solution:
When copying a timesheet the holiday_id is not copied
opw-2951062
closesodoo/odoo#100211
X-original-commit: e1e6ba48bb43ebfe9644368287f9bdf2fd1d561c
Related: odoo/enterprise#31347
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce
------------------
1) Install project_timesheet_holidays and mrp.
2) Go to Manufacturing > Settings and enable Work Orders.
3) Log in as a user with access rights to Manufacturing but no access rights to HR.
4) Create a Manufacturing Order with a Work Order.
5) Go to Operations > Work Order and start the Work Order.
5) Click on "Done", you should get an AccessRight error.
---
This commit fixes this error by calling sudo before creating the timesheet leaves for each employee.
Follow-up of https://github.com/odoo/odoo/pull/94414closesodoo/odoo#99174
X-original-commit: 13718d26bb98713f5a533c1a53c7fc2c2abfaac2
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Larcin Vincent (vila) <vila@odoo.com>
This commit prevent user write on time off timesheets and create timesheet
on time off tasks and add test for this feature.
task-2826265
Part-of: odoo/odoo#90744
Steps to reproduce:
- Install Time off and timesheet modules
- Create a public holiday with no "working hours"
- Then edit it and add it with working hours used by some employees
Expected behavior:
Adding the working hours makes that the global time off meets the
requirements to create timesheets. Then the employee related to the
new "working hours" is going to have timesheets created for this
holiday.
Current behavior:
No timesheet is created.
Explanation:
The write function of the global time off only updated timesheets
when the dates where modified. We add the update in the calendar_id
modification case and with it the new conditions to create the
timesheets. (working hours = calendar_id)
opw-2879882
closesodoo/odoo#96226
X-original-commit: a255a743b5296570aab166a5e275a323a1792b60
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, when the employee is generated with the salary
configurator, the employee is archived since the employee will not
directly start in the company. Even if the employee is archived and the
timesheets are generated for this employee based on the global time offs
found in the future. The problem is the timesheets cannot be created
for archived employees and so a user error is raised.
This problem could also happen if the user creates an archived employee.
This commit fixes the issue by preventing the timesheets generation when
the employee created is archived. When this employee will be updated and
active field will be set to True, the timesheets generation will be
applied. In the inverse use case, when the user will archive an employee
and timesheets generated for the future global time offs will be removed.
opw-2887727
opw-2870739
closesodoo/odoo#95644
X-original-commit: 160afba28d88ddd9d84856cc90639586bc2ea7b6
Related: odoo/enterprise#29273
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
Before this commit, in time off form view, task field contains the private task.
So this commit fixes the issue by not displaying the private task in task field
of time off form view.
task-2733415
closesodoo/odoo#89674
X-original-commit: 76fcd0cfe5fc157f22825544e239f283831b49fd
Related: odoo/enterprise#26611
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, when the user cancels his validated time off planned
in the future, the timesheets generated for this time off are not
deleted. The problem is since the timesheets are not removed we could
have duplicated timesheets if the user adds a new time off in the same days
for instance, because the newest timesheets are generated and thus we have
duplicated timesheets generated instead of having only timesheets generated
for the newest time off.
This commit removes the timesheets generated for the time off when this
time off is canceled (=archived). Also, It also prevent the user to
manually unarchive the time off since this operation is not really
managed and could introduced eventual problems.
Related PR: #76722
Part of task-2791386
closesodoo/odoo#89246
X-original-commit: a9e63ebe32079e2215acafcd4bca15b371ee9bc2
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
Co-authored-by: William Braeckman <wbr@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>
Purpose
=======
The existing timesheets linked to a time off are unlinked once the
time off is refused (which is the only action on the interface for
validated time off).
But nothing prevents to set in a python code a time off directly
in draft to validate it afterward.
In that case, the timesheet is duplicated and is impossible to unlink
as this is forbidden for timesheets linked to a time off.
Specification
=============
Make sure before creating timesheets linked to a time off that there
is not remaining linked timesheets.
On the other hand, modify the method to generate the timesheets in batch.
X-original-commit: 46a3394b960ba344d49a4e99ae5a6a7d7392dbf6
Part-of: odoo/odoo#84269
Before this commit, we search the leaves in the same interval of the
public leaves.
This commit searches all leaves containing the public leave in their
interval to get all leaves and not create a timesheet for this public
leave for an employee is already off.
task-2665899
closes#79034
X-original-commit: ca6c164075d83e6bace2451888f8a2365b769e1a
Part-of: odoo/odoo#79291
Description of the issue/feature this PR addresses:
A traceback appears when a time off is at the second approval stage and approved with several employees assigned to the time off.
https://www.awesomescreenshot.com/video/5408638
Current behavior before PR:
When validating a time off that is in the second approval stage with several employees assigned to, a traceback appears
Desired behavior after PR is merged:
No traceback appears when validating a time off that is in the second approval stage with several employees assigned to
task-2657656
closesodoo/odoo#77625
X-original-commit: aaa7c5bf10089eb8953f46cccb2e93aa3a20fa35
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Generate timesheet entries for each employee when a global time off is created
if module_project_timesheet_holidays is true.
This only impacts the employees with the corresponding resource calendar
The entries are linked to the project and task set in the settings.
The number of hours timesheeted corresponds to the timeframe during which both the global time off
and the working hours of the employee overlap (same behavior as for regular time off).
If the global time off is modified or deleted, the timesheet entry is adapted accordingly.
Task-2352428
Closes#67021
Co-authored-by: Laurent Stukkens (LTU) <ltu@odoo.com>
Co-authored-by: jdoutreloux <jud@odoo.com>
off.
When validating a time off with a company-less time off type, if the
time off type is configured to create timesheet entries in a project, a
multi-company security rule could be triggered by accessing the project.
We now check that the company of the task is valid in the current
context (it would make no sense to have an employee work on a task from
another company anyway) before creating the timesheets.
Closesodoo/odoo#75308
Task ID: 2628148
closesodoo/odoo#75579
X-original-commit: 29662626f7d67480926fbb12986ca644d213151c
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: William Braeckman (wbr) <Williambraecky@users.noreply.github.com>
Purpose of the commit is to improve the usability and onboarding
of the project app.
So in this commit, done the below changes:
- Rename column "Kanban state" in list view screens
- Hide column "analytic account" when not needed
- Do not show "Internal" project
PS: Moved leave_timesheet_project_id into hr_timesheet and rename
it as internal_project_id and we used it in the domain in the
kanban/action to the kanban in order not to have it in the result.
closesodoo/odoo#68857
Taskid: 2451722
Related: odoo/upgrade#2479
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Purpose of the commit 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.
So in this commit, re-word the several validation and usererror message
and als make the timesheet_task_id field required when the
timesheet_project_id field is set,
closesodoo/odoo#70796
Taskid: 2513067
Related: odoo/enterprise#18386
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Restore Project Kanban view for mobile.
Added a name for the default stage of the tasks in the Internal project
Removal of redundancy for the creation of the Internal project and its tasks
Fix task_reccurrence for the type 'after'. (too much task created or bad task created)
Task-2326258
closesodoo/odoo#64607
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
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
Xavier Bol (xbo)