This data is used in the chart of account definition and could put
the end user into a bad situation.
Related ticket: 3790614
closesodoo/odoo#158875
X-original-commit: f48c30181e1335ef72c60ca9e7d14b7f4aa42359
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Tremendous amount of support tickets (ex: 3800405) are opened because the user_admin
has been removed and is referenced everywhere, leading to tracebacks or
the impossibility to install a new application as res.group configurations
all relies on this, like:
<record id="group_helpdesk_manager" model="res.groups">
<field name="name">Administrator</field>
<field name="category_id" ref="base.module_category_services_helpdesk"/>
<field name="implied_ids" eval="[(4, ref('group_helpdesk_user'))]"/>
<field name="users" eval="[(4, ref('base.user_root')), (4, ref('base.user_admin'))]"/>
</record>
We could adapt all the occurences (severeal hundreds) to ensure robustness
but this won't prevent developer from introducing new use cases + the user
can be archived instead if we want to remove him from the pricing.
closesodoo/odoo#158885
Taskid: 3802440
X-original-commit: b55994b4c5e737aae593eb0419f96347ad90bebb
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Lots of tickets (e.g. 3775298) are created because the default menu has been deleted,
leading to the impossibility to install a new module, as the parent_id
for new menus like /shop or /event are directly referencing the
website.main_menu record, or to the impossibility to create a new
website.
Task-3802440
closesodoo/odoo#158879
X-original-commit: adb1dcfd0a150ab4706a09a29ae8921fb94fa463
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Those master data would break the basic accounting pdf generation flow
as those are widely used and it is not expected from end users to delete
them.
Example of support ticket from that issue: 3790875
closesodoo/odoo#158637
Taskid: 3802440
X-original-commit: b1ecc922503ff3a9618e89afd13659e37eb3fbed
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Lots of tickets are issues when the end user deleted this product
category, leading to the impossibility to install another carrier
as this category is referenced by all the specific carriers products
Ticket example: 3789116
closesodoo/odoo#158626
Taskid: 3802440
X-original-commit: 9383b6f4a5ef0394588c522efcc92e6f37a245cb
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
The time off duration is set to 0 when the related contract is set
as expired, then we remove the end date and set the contract back
to running.
That's because the check was done before calling super, hence the
contract is excluded from the candidates because it is still expired
without end date, which would make no sense when trying to retrieve
the related calendar.
closesodoo/odoo#157681
Taskid: 3806342
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In rework of accruals plan, we removed the possibility to set a time off type on the accrual plan directly.
The field has been removed from the form view, but not from the list view.
closesodoo/odoo#157366
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
From O.6 to 0.04 seconds to call get_allocation_data_request (15x faster)
and 574 to 25 requests for an employee with 10 years of XP in odoo.com.
Part-of: odoo/odoo#152311
Before this commit, when the company of the employees updated is not
in the allowed_company_ids of the current user (could happen in the
execution of a cron), an error is triggered saying we are not allowed
to create a timesheet for an employee inactive. The reason is because the
employee is not fetched in the check made in the timesheet creation because
of the company of that employee is not in the companies contained in the
environment.
This commit makes sure the companies in the environment are the ones
set on the employees created/updated, to be sure those employees are fetched
in the check made in timesheet creation.
closesodoo/odoo#151656
X-original-commit: ed6b02b6323691f79aa4ff466541eeb9768de1c9
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
On N elements resource.calendar.leave and M elements resource.resource recordsets,
the __get__ calls to 4 leave fields were done M time per loop, aka 4*N*M times.
This commit reduces the number of call to 4*N times, reducing the method executing
time for grid_unavailability from 9 seconds to +- 4.5 on odoo.com while displaying
all timesheets on Month view.
closesodoo/odoo#150408
Related: odoo/enterprise#54830
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Purpose
=======
Cannot currently save My Profile due to those 2 fields
- attendance_manager_id (allowed for groups 'Attendances / Administrator')
- employee_cars_count (allowed for groups 'Fleet / Administrator')
They are in the SELF_READABLE_FIELDS property, but the method
check_field_access_rights is not taking that information into account.
Part-of: odoo/odoo#139731
Purpose
=======
If not unlinked, it could make it impossible to create a not null
constraint on columns that are installed after l10n_ch before the
garbage collector dropped the existing wizard, leading to an error
like the following:
Table 'res_config_settings': unable to set NOT NULL on column 'ebay_currency'
Part-of: odoo/odoo#105119
Purpose
=======
When you create a vehicle, there is no sense in adding it to the
"registered column", you always start at the first stage. And this
is also very subjective to create a contract for one year. Why ?
In addition, the contract is empty, excepted for the date.
Specification
=============
- When you create a vehicle, his stage is : New Request
- On the contract form view, make the vehicle's field editable,
the driver is always related to the vehicle.
- Allow to add property fields on vehicle and model
closesodoo/odoo#127298
Taskid: 3349871
Related: odoo/enterprise#43627
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
The partner is not private anymore, so avoid copying the private information
like phone and mobile when creating a partner (from the chatter for instance).
Only copy needed and unavoidable pieces of information like the partner name
and the email address.
closesodoo/odoo#130982
Taskid: 3414035
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
2 commits were making impossible to define a default account on a
miscellaneous account journal. However, this is used in payroll
to auto-balance unbalanced moves.
After a discussion with the related team, it has been decided to
revert both commits, which were breaking other use cases as well.
Revert "[FIX] account: fix the domain of default_account_id from account_journal"
This reverts commit b09f06f986.
Revert "[IMP] account: remove default account on misc journal form view"
This reverts commit f2c0bc321b.
Part-of: odoo/odoo#124222
Purpose
=======
Currently the wage_type and the schedule pay are defined on the
salary structure type level, preventing users paying different
employees on the same structure with different salary types or
periodicity, which is a employee choice on certain countries,
like Mexico or the USA.
Specification
=============
Move the logic at the contract level, but keep the structure
type field definition to be used as default values.
Part-of: odoo/odoo#124222
PURPOSE
=======
Starting from 16.0 we introduced some reports to log skills history, skills evolution.
It means that the skill model is linked to another model, preventing us to delete it.
Usually, we use the message "link to x, archive it instead", but archiving a skill will only be possible from v17 (new task)
So, we need to be able to delete a skill on v16
closesodoo/odoo#131300
Taskid: 3456843
X-original-commit: d9672b55e7a596778fd542541f39e5216c06cb40
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Billing officers / HR officers have access to all bank accounts
- Internal users only have access to bank accounts that are not linked to an employee
- Portal/Public users have access to nothing.
TaskID: 3101400
Purpose
=======
It is currently impossible to display a json field on a form view without
defining a specific widget.
Allow displaying the json field in its simplest form, aka the stringified
content in readonly mode.
TaskID: 3101400
No need to hide the chatter to recruiters, as the salary configurator
has been improved to avoid posting sensitive data on the application
form itself.
TaskID: 3101400
Use the application form partner as work contact when converting him into
and employee.
Use the employee work contact as user partner on user creation.
The goal is to have only 1 partner over the whole recruitment process
flow, instead of three, thus reducing the confusion for end users who
don't really know who to choose.
TaskID: 3101400
- Improve performances, as the ir.rule restricting private partners
visibility is also applied on res.users by inheritance, on each
prefetch.
- Solve the issue of partners set as followers on records (eg: application
form) and then made private, making them impossible to contact via the
chatter.
- Solve the multiple access issues when trying to access the bank
account, or the private address for non HR people like the accountants
forcing the usage of sudo in the business code.
TaskID: 3101400
Improve usability of employee form. It is confusing for end users
to create another record to encode the employee address.
Move all the private information on the hr.employee record itself.
Remove the M2O address_home_id.
TaskID: 3101400
From 7s to 2ms for this query with 2.6M records
explain (analyze, verbose, buffers)
SELECT "hr_work_entry"."id" FROM "hr_work_entry" WHERE
(
("hr_work_entry"."active" = true) AND
(
(
("hr_work_entry"."state" in ('validated', 'draft')) AND
("hr_work_entry"."contract_id" in (548259))
)
AND
(
(
(
(("hr_work_entry"."date_start" >= '2023-05-01 00:00:00') AND (
"hr_work_entry"."date_start" < '2023-05-31 23:59:59.999999')
) AND
("hr_work_entry"."date_stop" > '2023-05-31 23:59:59.999999')
)
OR
((("hr_work_entry"."date_start" < '2023-05-01 00:00:00') AND
("hr_work_entry"."date_stop" <= '2023-05-31 23:59:59.999999')) AND
("hr_work_entry"."date_stop" > '2023-05-01 00:00:00'))
) OR
(("hr_work_entry"."date_start" < '2023-05-01 00:00:00') AND
("hr_work_entry"."date_stop" > '2023-05-01 23:59:59.999999'))
)
)
)
ORDER BY COALESCE("hr_work_entry"."conflict", false) DESC,
"hr_work_entry"."state" ,"hr_work_entry"."date_start"
;
closesodoo/odoo#124108
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
=======
When you start a new trial of an app without demo data, you
want to have everything perfect and ready for your own configuration
closesodoo/odoo#122308
Taskid: 3328654
Related: odoo/enterprise#41423
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Currently the chatter of a private event is unavailable to excluded users
but a end user might be confused as no explanation message is currently
displayed on the chatter.
closesodoo/odoo#120545
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Will be reintroduced properly afterward. Currently, even if the
field is defined using ondelete='set null', the M2M relation
doesn't handle the fact that the target table is a real model
and not a simple relational table.
closesodoo/odoo#116880
X-original-commit: f58d2ad669710a353263e418bbf69f5f49145cac
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This could prevent the user deletion if linked to a record of this
type, like a auth_totp.device which inherits from this model.
Part-of: odoo/odoo#114656
Purpose
=======
Currently the on_delete='restrict' implicit constraint prevents
the user deletion in case it's linked to a forum post vote.
Set the on_delete attribute to 'cascade' as the record is not
really a critical data.
Taskid: 3222941
Part-of: odoo/odoo#114656
Purpose
=======
Currently the on_delete='restrict' implicit constraint prevents
the user deletion in case it's linked to a personal calendar filter
record.
Set the on_delete attribute to 'cascade' as the record is not
of any usage without the user anyway.
Taskid: 3222941
Part-of: odoo/odoo#114656
Purpose
=======
Currently the on_delete='restrict' implicit constraint prevents
the user deletion in case it's linked to a mail.activity record.
Set the on_delete attribute to 'cascade' as the record is not
of any usage without the user anyway.
Taskid: 3222941
Part-of: odoo/odoo#114656
Purpose
=======
Improve the portal user deletion by preventing timeouts and
avoiding several rollbacks causes.
Specifications
==============
- Move the portal users deletions from autovacuum to its own cron.
On big databases such as odoo.com, deleting a res.users takes
more than 1 minute. Move the whole process into its own scheduled
tasks.
- Commit the deletion at each user. As said previously the deletion
can be expensive, so commit what has been done to avoid having to
delete the same user again in case of rollbacks or timeout.
- Delete the user and the partner separately. If the partner is used
in a sales order for instance, the unlink is possible for the user
and not the parner. It allows to unlink the user and keep the
partner in case it cannot be deleted.
- Re-call the cron into another transaction in case there are too many
users to delete, instead of waiting next call, that is supposed
to occur the day after.
Taskid: 3222941
Part-of: odoo/odoo#114656
Yannick Tivisse