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
Steps to reproduce:
-------------------
- create two employees (A and B);
- create a user;
- add the user in Related User of employee A;
- remove the user;
- add the user in Related User of employee B;
- change the Work Email of the employee B.
Issue:
------
The Work Email of the employee A is also updated.
Cause:
------
When we add a `user_id` to an employee,
we update the `work_contact_id` field.
Fields `mobile_phone` and `work_email` are inverse fields.
When we modify them, the `_inverse_work_contact_details`
method is called.
We update the `work_contact_id` linked to the employee.
When we delete an employee's `user_id`,
we don't update the `work_contact_id`.
Therefore, when we update an employee's `work_contact_id`,
we call the `_compute_work_contact_details` method
method for all employees who have the same `work_contact_id`.
The result is that we modify the `mobile_phone` and `ẁork_email`
fields for all employees linked to the `work_contact_id`.
Solution:
---------
Differentiate the case where the `user_id` is `False` (>< `None`)
when it is modified and does not contain
a value to "synchronise" the `work_contact_id`.
opw-3338188
closesodoo/odoo#123965
X-original-commit: 85ab51c7cf7c8ee011a903a9460e2aff1296f215
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
This reverts commit 14d97ec2
We revert this to keep the same design when changing password for
one or multiple users.
Task-3184727
Part-of: odoo/odoo#112806
* = bus, calendar, crm_livechat, hr, hr_holidays, im_livechat, mail_bot,
mass_mailing, privacy_lookup, test_discuss_full, test_mail,
test_mail_full, website_crm_livechat, website_livechat, base
In preparation of splitting discuss and mail modules.
Part of task-3265211
closesodoo/odoo#118354
Related: odoo/upgrade#4553
Related: odoo/enterprise#39661
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose: The form view is more intuitive then list view in case
user wants to change the password only for one user.
task - 3105178
closesodoo/odoo#109869
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, when the parameters given to the
`_search_part_of_department` is:
- `operator='!='`
- `value=False`
Then the domain returned by the method does not take into account the
False value.
This commit fixes the issue by changing the `=` into `!=` when the value
is False instead of changing `!=` into `=` when the value is False.
closesodoo/odoo#108589
X-original-commit: 814cdc9a7bccf4dca1cf93403295cf1280ca6c10
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
When creating an employee with an associated user, the work email of the
employee is copied from the user (or actually the partner associated with the
user).
However since this [commit], both the mobile_phone and work_email fields on the
employee are computed fields based on a linked partner in the work_contact_id
field. This partner is created on the fly if it did not previously exist.
Both of these behaviors interact in such a way, that the linked partner of the
employee is created automatically using the email from the linked partner of
the user. This is a bug, since both linked partners of the employee and the
user should be the same.
The bug is easily resolved by adding the work_contact_id field directly to the
values dict for the creation of the employee (instead of the work_email).
Reproduction steps: the bug can be easily triggered by repeatedly installing
and uninstalling the employees app. An extra partner gets created for each
employee in the master or demo data, after each install/uninstall cycle.
[commit]: https://github.com/odoo/odoo/commit/3c6060b7bbe9c67aca8073ef43c1e89fb7e820ca
opw-3031187
closesodoo/odoo#108045
X-original-commit: 35b7e0e128f1cfd72c11ebb16d68bc48fdcbdb57
Related: odoo/enterprise#35004
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The test `test_employee_create_from_signup` was failing when the module
`auth_signup` was installed because of the missing partner.
closesodoo/odoo#107243
X-original-commit: 2688f9bb00f9cb049ff11bbe4443adc66ee05941
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps :
- On a new DB (no demo data). Say created at 15:00. - Go to planning.
- Add a shift for today.
- Set the dates from 08:00 to 17:00.
Issue :
The 'Allocated Time' = 02:00.
Cause :
We used to count from the resource creation min to the departure max. So, in this case, not from 08:00, but from 15:00.
While this might seem logical, it confuses users in onboarding.
Fix :
Calculate the whole time, regardless of the resource lifespan.
Notes :
- Similar issues solved with this commit :
> Once the shift validated, the avatar progress bar uses
the same allocated time.
> Same in Project Task gantt view.
- When contract is installed, if the resource does not have a contract, the Allocated Time = 0. Now, it is calculated from the resource calendar.
task-2983993
closesodoo/odoo#102732
X-original-commit: 6a61d1c4c56075ade36f6f32e7a61f1f6c771a6f
Related: odoo/enterprise#32547
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
It was no longer possible to load the My Profile for users with an
employee that were not HR Officer.
In the `get_views()` method, the 'search' view was requested after the
'form', thus it omited the fields requested as SUPERUSER in
`get_view()`.
closesodoo/odoo#99750
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Introduced by #85428closesodoo/odoo#99672
X-original-commit: e6cef5ab9ec189f1f0b86e21a1400859f021ba06
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
The cache key of _get_bindings was not super efficient.
The result of _get_bindings is cached,
but its performance was altered by the cache
key which requires to fetch the user groups for each call to
_get_bindings.
Besides, as there is a lot of possible group
combination, this resulted in a lot of possible cache keys,
and therefore a lot of cached values.
This revision aims to make _get_bindings more efficient
by:
- do not use the groups in the cache keys (less cached values)
- filter out actions not available to the user groups after
retrieving them from the cache
- use has_group to do the above, which is itself cached as well,
and therefore do not need to fetch the user groups
at each call to get_bindings.
In addition, move get_bindings from `get_view`
to `get_views`. If there was 3 views asked by `get_views`
(let's say kanban, list, form)
`get_bindings` was being called 3 times, through `get_view`
with each time the same arguments and therefore the same result :-).
Moving it to `get_views` allows to call it only once for all view types
requested, and for the web client it doesn't change much,
as it always request the toolbar/get_bindings through `get_views` only.
In addition, add the lang to the cache of _get_bindings.
it was actually a bug not to put it: if you had 2 users
with the same group set, using 2 different languages,
the user accessing first the get_bindings would cache
the action names within his language, and then the second
user would see the action name within the language of the first user
:-).
Before
```py
In [1]: %time for i in range(1000): self.env['ir.actions.actions'].get_bindings('res.partner'); self.env.invalidate_all();
CPU times: user 790 ms, sys: 104 ms, total: 893 ms
Wall time: 1.7 s
```
After
```py
In [1]: %time for i in range(1000): self.env['ir.actions.actions'].get_bindings('res.partner'); self.env.invalidate_all();
CPU times: user 23.5 ms, sys: 9.12 ms, total: 32.7 ms
Wall time: 36.9 ms
```
Part-of: odoo/odoo#99417
The render API was confusing as mixing the access to the report and
the rendering env.
The ambiguity was present for code such as
`report.sudo()._render(record_ids)` where it was not clear if the
`sudo()` is needed to access to `report` or to `record_ids`. For low
priviledge users (such as portal or public), it was common to use
`report.with_user(SUPERUSER_ID)._render(record_ids)`.
This PR changes the render methods signature to be `api.model`. The
`report_ref` can be:
- ir.actions.report external id
- ir.actions.report id
- ir.actions.report recod
- `report_name` value
This will allow to call the report methods with any user and no longer
need to use `with_user(1)` to render reports as public user.
Task-id 2670865
closesodoo/odoo#91341
Related: odoo/upgrade#3650
Related: odoo/enterprise#27323
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Refactor the `load_views` API so it no longer sends multiple times the same
fields description.
e.g.
When `load_views` is called to get the kanban, tree and form views,
the list of fields of the model was sent 4 times:
- Once for each view, with only the fields used in the view,
in `['fields_views']['kanban']['fields']` for instance
- Once globally, with all the fields of the model, in `['fields']`
The goal of this revision is to change that so it sends the list of all fields
only once.
In addition, if a view contains x2many fields,
the fields description of the comodel is also sent.
It was sent in the `views` key of the view fields dict.
e.g.
When calling `load_views` of `res.partner` to get the kanban,
tree and form views,
the `res.partner` fields description was actually sent 6 times:
- Once for each view
- Once globally
- Once for each view of the many2many field `child_ids` of the form view, in
- `['fields_views']['form']['fields']['child_ids']['views']['kanban']['fields']`
- `['fields_views']['form']['fields']['child_ids']['views']['form']['fields']`
The change suggested in this revision is to:
- Remove the fields description for each view in `['fields_views']`.
As it no longer contains the fields,
the key becomes `['views']` instead of `['fields_views']`.
- Replace the dict key `['fields']` by `['models']`,
which is a dict with as key the model name and as values
the model fields description. It contains the fields description
for all models implied in the view:
the model of the main view and the model of all one2many and many2many fields.
With this change, the fields description will only be sent once by model
implied in the view.
In addition, the web client was getting the information about the fields
sometimes in the global fields description list (e.g. `['fields']`),
sometimes in the fields description list of the view type
(e.g. `['fields_views']['form']['fields']`),
making it a pain to try to make changes / performance gain
in these field description dictionaries, because you never knew in which dict
the web client was getting its info.
Now, as there is only one place to get the fields description from,
it's clearer and cleaner.
- one2many and many2many fields views are passed directly in the main view
architecture rather than being put in the `views` key
of the field description.
This is actually easier to treat by the web client,
and this will allow in a future work to cache an entire view in one block
of text rather than having to combine multiple cached blocks of text
to return one view.
- one2many and many2many fields which do not have directly embedded views
have their views directly injected in the architecture,
so the web client doesn't have to do RPC calls to `load_views`
for each one2many and many2many fields not having embedded views.
For instance, this allow to reduce the number of RPC calls to `load_views`
from 8 to 1 when loading the form of `product.product`.
Currently, this behavior is limited to 1 level deep but we consider making it
go all the way down in future works. We did not do it for the moment because
in certain cases it rises the processing time and the size (bytes) too much.
e.g. the sale.order view can be 5 levels deep,
meaning you can reach 4 dialogs on top the main view.
```
sale.order form > order_line > sale.order.line form > invoice_lines >
account.move.line form > asset_ids > account.asset form >
depreciation_move_ids > account.move form.
```
This will also benefit in future works to cache an entire view in one block
of text rather to having to combine multiple cached block of text
to get one view.
- `fields_view_get` becomes `get_view`.
As it no longer returns the fields description,
keeping the `fields` in the name `fields_view_get` no longer makes sense.
Hence removing `fields` from the method name, it becomes `view_get`.
As it gets renamed anyway, we take the opportunity to rename it `get_view`,
which is more in line with the general getter/setter guidelines
in the model object world.
- `_fields_view_get` becomes `_get_view`. For the same reasons than above.
- `load_views` becomes `get_views`.
This is not mandatory, there is no technical reason to rename `load_views` as
it practically sends the same info as before,
the view architectures and their fields description. Just in another way.
We just take the opportunity of this pull request to suggest a cleaner API:
`_get_view`, `get_view` and `get_views`.
- Arguments `toolbar=False, submenu=False` fo the methods
`_fields_view_get` and `fields_view_get` are converted to a kwargs `**options`
in `_get_view` and `get_view`.
The rationale is that submenu was already no longer used (deprecated)
and the mobile options is introduced.
The mobile options is necessary to tell the server to send the mobile views
for x2many fields (kanban instead of tree).
Instead of adding a new argument each time we add a new option to
`fields_view_get`, it seems wiser to have a kwargs `**options` to avoid
to re-write all overrides each time a new option is introduced.
- `_fields_view_get` returned a dict containing the arch in text and some of the
view information. Now, `get_view` returns a tuple with the view architecture
as an `etree` node, and the view as a browse record. The rationale is that all
overrides of `_fields_view_get` were about modifying the arch only
(e.g. changing the address format/re-organizing the address related field
nodes of the partner according to the company country).
To do so, all these overrides were doing `etree.fromstring` to parse the arch
which was sent in text to convert it to an `etree`,
then operations were done on the `etree`,
and then `etree.tostring` was called to convert back the arch to string.
With this change of signature to send the arch as an `etree`,
all these back and forth `etree.fromstring` -> `etree.tostring` are avoided,
allowing some performance gain and less code in the end.
- A cleanup of the keys returned in the dict of `fields_view_get`
has been performed in `get_view`:
- `fields` is removed, as explained above,
- `view_id` is renamed `id`,
- `name` is removed, it was unused by the web client,
- `type` is removed, it was unused by the web client,
- `field_parent` is removed, it was unused by the web client,
- `base_model` is removed, it was unused by the web client.
- `filters` is moved from the global dict returned by `load_views`
(now `get_views`) to the dict returned by `fields_view_get` (now `get_view`)
as it applies only to the `search` view type.
- Retro-compatible methods for the 3 methods
`fields_view_get`, `_fields_view_get` and `load_views` are provided,
with deprecation warnings in them.
- The web client could cache the model fields description
(as it already caches the views),
so it doesn't need to fetch them again if it asks for another view of a model
for which he already has the fields description.
If we do so, `get_views` could return only the list of models used by
the views, without the fields description as of now,
and the web client would then call `fields_get` independently only for
the models for which it doesn't have yet the fields description.
This would avoid the server to return the fields description
and to call `fields_get`, which is costly, for each `get_views`,
therefore gaining performances.
- Inject the views of the one2many and many2many fields all the way down,
unlimited depth level, as explained above.
- Cache with `ormcache` the architecture of back-end views.
This is already done for qweb views, it's not done for back-end views.
Therefore the postprocessing of the views is performed for each `get_views`,
which is costly, while the view architecture doesn't change for users
belonging to the same groups, according to the groups implied by the view.
This pull request is co-authored by
Aaron Bohy (aab) for the web client part and
Denis Ledoux (dle) for the server part.
Part-of: odoo/odoo#87522
* Redesign views
* New layout for the job kanban card + redesigned menu
* Create new reports
* Candidate Sources: get a better view on where applicants are
coming from;
* Time in Stage: shows how long an applicant is in the current
stage.
* Archiving a job archives applicants as well
odoo/enterprise#24816odoo/upgrade#3395closesodoo/odoo#85479
Taskid: 2738082
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Expected Behaviour
When a user goes to his own profile, he has two ways to change his password :
1. through the 'Account security' tab
2. through the 'Actions' > 'Change password' menu in list/form view
Both option should let the user change its password, or one of the two should
not be present
Observed behaviour
While the first one works as expected, the second option gives an error as
the user doesn't have the admin rights
Reproducibility
This bug can be reproduced following these steps:
0. Make sure to have the "Employees" app installed
1. Connect as an employee (e.g. demo/demo on runbot)
2. Click on your name at the top right, go to 'My Profile'
3. Click 'Action' then 'Change password'
Problem Root Cause
There is an override of field_view_get for the res.users model in the hr
module which elevates the user with sudo so that the user may modify their
own user in some capacity. The problem is that by elevating the ACLs of the
user, fields_view_get will also return actions that are not normally
available to the user (e.g. deletion of user profile)
Related Issues/PR
- opw-2735671
closesodoo/odoo#86116
X-original-commit: 6487a9ea7d25d14a86a7476b4b512f3681da7405
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
QWeb is the primary templating engine used by Odoo. It is an XML
templating engine and used mostly to generate XML, HTML fragments and
pages.
To create new XML template, please see :doc:`QWeb Templates documentation
<https://www.odoo.com/documentation/15.0/developer/reference/frontend/qweb.html>`
In **input** you have an XML template giving the corresponding input
etree. Each etree input nodes are used to generate a python function.
This fonction is called and will give the XML **output**.
The ``_compile`` method is responsible to generate the function from the
etree, that function is a python generator that yield one output line at a
time. This generator is consumed by ``_render``. The generated function is
orm cached.
In the graphic below you can see theresume of the call of the methods
performed in the IrQweb class.
Odoo
┗━► _render (returns MarkupSafe)
┗━► _compile (returns function) ◄━━━━━━━━━┓
┗━► _compile_node (returns code string array) ◄━━━━━━━┓ ┃
┃ (add technical directives: t-inner-content, t-tag) ┃ ┃
┣━► _directives_eval_order (defined directive order) ┃ ┃
┃ ┃ ┃
┣━► _compile_directives (recursive) ◄━━━━┓ ┃ ┃
┃ ┣━► _compile_directive ┃ ┃ ┃
┃ ┃ ┗━► t-if ━━► _compile_directive_if ━┫ ┃ ┃
┃ ┃ ┗━► t-foreach ━━► _compile_directive_foreach ━┫ ┃ ┃
┃ ┃ ┗━► t-* ━━► ... ━┛ ┃ ┃
┃ ┃ ┗━► t-inner-content ━━► _compile_directive_inner_content ◄━━━━┓ ━┛ ┃
┃ ┃ ┗━► t-tag ━━► _compile_directive_tag ━┫ ┃
┃ ┃ ┗━► t-call ━━► _compile_directive_call ━┫ ━━━┛
┃ ┃ ┗━► t-out ━━► _compile_directive_out ◄━┓ ━┫
┃ ┃ ┗━► t-field ━━► _compile_directive_field ━┛ ┃
┃ ┃ ┃
┗━━┻━► _compile_static_node ━┛
Part-of: odoo/odoo#81024
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.
Yannick Tivisse