Adds a new non stored field to make it easier to query all employees
from the active user's department and it's children department(s).
The result is guaranteed to always contain the active user's employee.
task-2700231
closesodoo/odoo#81472
Related: odoo/enterprise#22724
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit adds methods to easily obtain calendar validity per resource
for a given search period and get the work intervals per resource,
taking into account the validity of their calendars.
In hr, the create and departure date of an employee are taken into
account to compute the calendars validity.
In hr_contract, it looks for every contract of human resources with
employee of type student or employee existing in the search period and
consider the specific calendar of the contract as valid during the
contract-lifetime.
PR: #77362
task-2646630
In task 2404630 the avatar feature was created and no tests were written due to
the iminent freeze. This PR implements tests for the avatar feature, such as
avatar generation and placeholder logic.
task-2578233
closesodoo/odoo#79688
X-original-commit: 400b3fd93266f88832446c8f7422f6e14b958115
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Refactor the Environments object into a Transaction object, which is
bound to one cursor, and is no longer shared among several cursors.
The following methods/properties have been changed:
- Environment.envs no longer works (because of the design change);
- Environment.manage() is deprecated (no longer useful);
- Environment.reset() is now an instance method;
- env.clear_upon_failure() is deprecated in favor of cr.savepoint().
closesodoo/odoo#75598
Related: odoo/enterprise#20451
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Xavier Dollé <xdo@odoo.com>
`result` might be a Markup object (eg during tests) or a bytes-like object.
Step to reproduce: click on "Send by Mail" on a SO -> Traceback
Step to reproduce (2):
- Install website_sale
- Add something to the cart
- Go through checkout and click on Pay Now
- Crash, 500 error page, as this step is trying to generate the SO PDF to send
by mail to the customer, which tries to encode a bytes-like object.
```
AttributeError: 'bytes' object has no attribute 'encode'
```
But if you do that flow during a test, eg
```
./odoo-bin -d mydb --test-tags=.test_02_admin_checkout
```
You have a Markup object, thus you had to encode it.
Now, even during test, we return a bytes-like object.
Related to #68299
Community: https://github.com/odoo/odoo/pull/75377
Enterprise: https://github.com/odoo/enterprise/pull/20449
Part-of: odoo/odoo#75377
In order to limit encoding decoding, the _render method returns a
unicode string in the markup safe object instead of a MarkupSafeBytes
closesodoo/odoo#68299
Related: odoo/upgrade#2454
Related: odoo/enterprise#17270
Signed-off-by: Antony Lesuisse (al) <al@openerp.com>
Problem
-------
A user with no read access on private employee (hr.employee) model
will get a bad query error if he search on employee_id on res.users
The new domain evaluation system generate query like this
SELECT "hr_employee"."user_id" FROM "hr_employee_public"
because the _search of hr.employee was not returning the search result
from the right table
Solution
--------
Return a search result from the right table
closesodoo/odoo#63036
X-original-commit: e542c4121af098372c250a081635a44829e50406
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
New module for supporting two-factor authentication via time-base
one-time-password (TOTP).
Users (including portal users) can choose to enable two-factor auth in
their user account settings, by scanning a QR code and adding it to an
authenticator app, such as Google Auth, 1Password, etc.
When two-factor is enabled, password-based non-interactive RPC is only
possible by using API keys.
Co-authored-by: Olivier Dony <odo@odoo.com>
Modules holding tests and helpers
* link_tracker: mainly mock, asserts and tools for link tracker tests
(MockLinkTracker);
* mail: mainly gateway mock and base for mail tests
* MockEmail -> mocks for mail gateway;
* MailCase -> tools and asserts for mail tests;
* MailCommon -> base for mail functional tests);
* sms: mainly SMS gateway mock and base for sms tests
* MockSMS -> mocks for SMS gateway;
* SMS Case -> tools and asserts for mail / SMS tests;
* SMSCommon -> update of MailCommon with SMS capabilities);
* mass_mailing: mainly asserts and tools for mass mailing tests
* MassMailCase -> update of MailCase for mass mailing tools and asserts;
* MassMailCommon -> update of MailCommon with mass mailing);
* mass_mailing_sms: mainly asserts and tools for mass SMS tests
* MockMassSMS -> update of MockSMS for mass SMS tools and asserts;
* MassSMSCommon -> update of MassMailCommon with SMS capabilities);
Modules for tests
* test_mail: module for mail app tests (TestMailCommon);
* test_mass_mailing: module for mass mailing app tests (TestMassMailCommon);
* test_mail_full: tests integrating all discuss features, currently mainly
mail and SMS (TestMailFullCommon);
Enterprise: update test_mail_enterprise and test_marketing_automation
Task ID 2247037
Community PR odoo/odoo#50384
Enterprise PR odoo/enterprise#10266
Upgrade PR odoo/upgrade#1122
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
"Edition" is a French-English false friend word. "Edition" in English
means "version" whereas "edition" in French means "editing". This commit
updates user facing strings/documents that incorrectly use "edition" instead
of "edit" or "editing". Attempts were made to clean up English around
"edition" usage so please excuse any errors from lack of context
knowledge. Code comments and names incorrectly using "edition" were NOT
updated.
The Common partner contact setting is removed from general settings because its
behavior wasn't really clean from a technical point of view
(disabling the rule on partner access) and wouldn't work as well with new
multi-company logic.
The default logic of sharing partner will be kept, but when someone wants to
limit partner sharing, he will do so partner by partner, by
setting the company_id.
Also, the default company_id on a partner will be blank so default partner
will be a sharable by multi-company.
when the partner is created at the time of user creation then the partner's
company will be the same as user's company.and when the partner is created at
the time of company creation(partner related to company) then the company of
partner will be newly created company.
task-2024446
Closes: #35266
Currently, a simple user no longer see fields protected
by groups in his profile.
When retreiving the view arch, `sudo()` is used to bypass
the group protection.
But since commit 1e6c3be, `.sudo()` no longer changes the user.
Hence, groups are still checked for the simple user.
To fix the problem, the view arch should be retrieved with
a user with all groups (SUPERUSER). This assumes that
SUPERUSER has effectively all groups.
closesodoo/odoo#35486
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
The `private_email`, `last_check_in` and `last_check_in`
fields were added by e9d9898 to the
profile view but not in `SELF_READABLE_FIELDS`.
A simple user was therefore not able to read the field and
access his profile.
To avoid any similar oversight in the future, a test is added
to ensure a simple user is able to read all fields in
the profile view.
Purpose
=======
This commit tests some behaviors with multi company
mode after changes brought by f847a46.
Specification
=============
Check that a report printing for several records on
different companies:
- Works if the context is correctly set, i.e. both
companies are in the allowed_company_ids
- Doesn't work if the context is not correctly set
Purpose
=======
1/ Robustness & security: right now it is not easy to understand and do something
clean in term of security (hr people vs employees, private info vs public). A
HR officer doesn't know if he can write something on the chatter. Currently, a
note will be visible for all the employees who have access to the employee form
view for example.
2/ In term of business, it makes sense to let a hr manages payroll stuff (contract,
employees private information, ... and other employee see public information
(résumé and work information)
Specification
=============
Introduce 2 new models:
- hr.employee.base (AbstractModel): This represents the basic skeleton
model on which the shared fields and methods between the public and
the private employees models.
- hr.employee.public (_auto=False): This is a sql view based on the
employee values, readable for an internal user (i.e. an employee).
The model hr.employee is not readable anymore for an employee.
There are now 3 ways to access the employee data:
1/ From the hr.employee views. HR officer access rights are required
2/ From the public profile. The public data for an employee are accessible
but can't be modified.
3/ From the 'My Profile' menu. A classic employee can access its own
data from there, and can modify them.
Purpose
=======
Managing people's names is hard.
The full name is stored in a single field.
But is it first name first? Last name first? How many names?
We don't want an onchange to automatically change names
for which we might have spent a lot of energy correctly
formatting in the database.
Specification
=============
Remove the automatic sync between the user's name
and the employee's name when a user is linked to
the employee.
TaskID: 1953003
closesodoo/odoo#32521
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
General Purpose
===============
We want an 'Employee profile' gathering every data about an employee.
The main form view is modified to become this employee profile.
A user can also see his own profile through the Preferences menu.
The new profile replaces the current Preferences view if the hr module is installed
and the current user is linked to an employee.
A user should be able to see and edit his own profile.
*Problem*:
Many fields on hr.employee are protected by groups="hr.group_hr_user".
Therefore, a regular user cannot see or edit those fields.
This protection must be bypassed to allow read/write access
to the regular user's own data.
A similar mechanism already exists for res.users (for Preferences)
The better (least worst) solution found is to reuse this mechanism by adding related fields on res.users.
Pros:
- Don't change security access on hr.employee
- Don't implement yet another custom security layer, risking to add new security breaches
- A lot of fields are added by other modules on hr.employee.
It would have required to integrate them with the custom security layer.
- Fields added by other modules on the user's preferences view (normal view, not the profile)
are automatically included in the employee's profile view.
- Allow the hr.employee form view to be different than the user profile accessible
through the Preferences menu.
E.g. add custom buttons only relevant to the logged in user such as "Request a leave".
Cons:
- Each field from hr.employee that you want to appear on its profile
must be added as a related field on res.users
- Those related fields must be added to user's preferences view (duplicate views)
- They also must be added to SELF_[READABLE | WRITABLE]_FIELDS
Note:
When the front-end loads the views it gets the list of available fields
for the user (according to its access rights). Later, when the front-end wants to
populate the view with data, it only asks to read those available fields.
However, in this case, we want the user to be able to read/write its own data,
even if they are protected by groups (groups are kept on the related fields on res.users).
The front-end need to be made aware of those fields by sending all field definitions.
hr_attendance
=============
This commit integrate attendance in the new employee profile.
It also adds a stat button to this employee profile showing
the number of hours worked last month.
Remove the boolean computed field 'manual_attendance'.
This field is just a shortcut to add/remove the employee's user
in the "Manual Attendance" group.
The checkbox is confusing on the employee's form and this should
be done through the normal group management screens.
hr_presence
===========
Display the presence status on the employee kanban template.
The status is a colored chip which can be green (present),
orange (to define) or red (absent).
Currently, the presence status is only computed when accessing
the report view. As this commits displays it on the employee kanban,
it should be updated more frequently.
The state should not be updated every time the kanban view is loaded
since the computation is a bit heavy. Instead: add a cron to update
status every 15 minutes.
-> The status is accurate on the report view (status is still updated
when loading the view)
-> The status in accurate at 15 minutes on the kanban view
[ADD] hr_attendance_presence
============================
Bridge module between hr_attendance and hr_presence.
This commit integrates hr_presence module in the employee
profile and adds the presence status on the employee kanban view.
But hr_attendance adds at the same place a similar status icon for
checkin/checkout.
This bridge module makes the status from hr_presence invisible as
hr_attendance should be the main presence control mechanism.
Also, this commit adds the ability (through a new setting option)
for hr_presence to take into account checkin/checkout to determine
the presence status.
l10n_be_hr_payroll
==================
integration with employee profile
Purpose of this commit is to use the newly introduced helper to create
test users in a quick way and reduce code duplication.
This commit is linked to task ID 1889703 and PR #27526.
Purpose of this commit is to allow to make private channels linked to
an HR department with an auto subscription.
It will ease the use of discussion channels among employees of a given
department. Moreover auto subscription is useful to avoid having to
manually synchronize channel members and department members.
This commit is linked to task ID 1848526 and closes PR #26650 .
Co-authored-by: Gert Pellin <gpe@odoo.com>
Co-authored-by: Richard Mathot <rim@odoo.com>
Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:
- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
translated
The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).
Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).
This commit correct all the external ids tagged as from base or other incorrect
modules.
William Braeckman