before this commit, in resume we are able to put end date less than start date
which is not possible in real life.
make change in constraint to check selected end date is greater than start date.
make changes in demo data of end date which are according to new changes.
task-3397726
closesodoo/odoo#136326
X-original-commit: 1cf56688126d3f0a1d27f4ed5ee995c4dcd956bc
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
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>
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
Before this commit, the name and description of resume lines
were not translatable.
task-3323624
closesodoo/odoo#121166
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce:
- enable "Skills Management" in Employee app;
- create a new employee;
- add skill by creating a skill level ("Create and edit").
Issue:
A traceback appears.
Solution:
Add the default skill type in the context
so that it can be used during creation.
opw-3269030
closesodoo/odoo#118555
X-original-commit: d553527403f4352da23673b91052e706841e1438
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Prior, by default Skill history report goes to stacked view.
Which is not informative for the kind of information that is displayed.
task - 2993831
closesodoo/odoo#101656
X-original-commit: 1951b56d91dc17ec8d81257e8c431f7a24420e2b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
after this commit:
- you are able to create new skills from an appraisal form
- you select skills more easily
taskID #2766619 [Appraisals] Skills usability
closesodoo/odoo#84892
Related: odoo/enterprise#24518
Signed-off-by: Kevin Baptiste <kba@odoo.com>
It was possible to have negative Progress on a skill, which doesn't make
sense.
Here we ensure it's a valid percentage between 0 and 100 inclusive.
odoo/upgrade#3238closesodoo/odoo#84442
Taskid: 2762009
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Description of the issue/feature this PR addresses:
When you want to add/select new skills, it could be more clear.
Current behavior before PR:
When you want to change a skill level, you have to select a skill level to see its progression value
Desired behavior after PR is merged:
- The progression value is displayed beside the skill level in the dropdown list.
- In the appraisal module, the same thing applies to skills, which also feature the skill type in the dropdown list.
task: #2719642 [Skills] Overwrite name_get()
skill dropdown
[IMP] hr_skills: do not display skill option if skill_type is unselected
closesodoo/odoo#82202
Related: odoo/enterprise#23237
Signed-off-by: Kevin Baptiste <kba@odoo.com>
- Reset skill levels on skill/skill type change
- Improve form view
- Add a sequence on hr.skill
closesodoo/odoo#73305
Taskid: 2575351
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
No need for selection fields
If in global variable, the _lt should be used instead
closesodoo/odoo#31211
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When a employee succeed a course or a certification, a new line
will be added in resumé of employee profile.
+ [FIX] hr_skills: remove sequence to sort resumé
Actually, sorting a resumé doesn't work because we add new line for
title in the array.
With this commit, all sequence are removed. The resumé is sorted
by date and skills are sorted by level.
closesodoo/odoo#31764
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Consultancy companies need resumé and skills of their consultants.
For big projects, they often need to send them to their customers.
These informations are also useful to statistics.
Specification
=============
New models
----------
1/ `hr.resume.line.type`
Types of resumé lines. e.g. *Experience*, *Education*, *Hobbies*
2/ `hr.resume.line`
It is a line in the resumé of an employee.
3/ `hr.skill`
Name of a skill. e.g *French*, *Python*, *Piano*
4/ `hr.skill.type`
Skills can belongs to a particular type. A skill type has skill levels associated.
e.g. *Languages*, *Dev*, *Music*
5/ `hr.skill.level`
Levels available for a particular skill type. Each level has a label
and a progress (between 0 and 100) associated.
e.g. *Intermediary (20%)*, *Advanced (85%)*, *Expert (100%)*
6/ `hr.employee.skill`
These are skills which employees have. It links an employee with a particular skill
and level.
e.g. Mitchell has an *Intermediary* level in *Python*
Access Rights
-------------
Only a `hr_user` can create/edit `hr.resume.line.type`, `hr.skill`, `hr.skill.level`, `hr.skill.type`.
If employees are allowed to edit their infos (setting), they can also create/edit `hr.resume.line`,
`hr.employee.skill` for themselves.
UI
--
Resumé lines are displayed, grouped by type, in a new 'Resumé' tab in the employee
form. Resumé lines can be reordered (handle widget)
Emloyee skills are displayed in the Resumé tab, grouped by skill type.
pash-odoo