When rating with the smiley mecanism, the rating value will be 1,
3 or 7. The rating model allow value in range [0, 10]. When using
the star mecanism, usually, only 5 stars are used to introduced a
rating. This will set a rating value in the range [0, 5], which
is not aligned with the range of the model, nor the smiley range.
Purpose of this commit is to uniformize the range of rating, so if a
model is using both mecanism, the average will be correct. Solving
this problem implies to apply a conversion factor between the
database value and the displayed one.
Migration:
As only product.template was using star mecanism in odoo community,
a migration step should be applied to multiply of ratings of
product.template by 2.
Task-1941432
closesodoo/odoo#31141
This commit e84779749b factorize the check of
special access to post a message using a token mecanism, but it breaks the
case without token. Indeed, on some models, it is allow to post a message
on a document when having a certain access. This is handle with the
`_mail_post_access` attribute on model inheriting mail.thread.
Using this mecanism, a user that can read (or write) the document can also
post a message. This is used in the eShop to review product and in blog to
comment blogpost.
This commit restore posting a message without token. the normal access rights
will be applied by message post and raise if the user can not post message,
taking `_mail_post_access` into account.
The balance is now restored in the universe.
Task-1902304
Remove date_start in project.task model, because it is not
useful. Now using date_assign instead for reporting.
Add two ids in settings views to refer from enterprise modules.
closesodoo/odoo#31101
Before this rev., steps were consumed on 'mousedown' events. This
caused an issue with the RainbowMan displayed at the end of tours
(which closes itself on 'click' events outside its $el).
Here is what occured when the user clicked on the last step's
element:
- 'mouseenter' event triggered
- current step consumed, as well as the tour, and a RainbowMan
is instantiated and appended to the DOM
- 'click' event triggered
- RainbowMan closes itself because of that 'click' event
closesodoo/odoo#31148
Part of https://github.com/odoo/odoo/commit/f4ba72a7593b67595852fc52ec0997d3276dbc67
became useless after forward-port in the new editor. Indeed, that
commit handled what happened with data-editor-message attributes on
save but as the new editor can discard changes without reloading the
page, the forward-port of that commit made the code handle the attribute
removal on editor *close*.
closesodoo/odoo#31143
This merge proposes a new homepage for slides module evolving towards
an eLearning platform. This merge closes task 1936153 and PR #30770.
More generally this merge is linked to currently under heavy work slides
module update to eLearning [1][2].
It includes
* a new main page displaying top courses / channels. It displays 3 most
popular and newest channels as well as its ongoing courses (if logged).
Achievements and karma update done by eLearning community allow to
give a gamification look and feel;
* an 'All' page displaying all courses / channels. Tag groups and tags
allow to search / filter displayed courses;
* a new pimped and revamped display for main course / channel page;
* new demo data for slides and small addition of demo data in bridge module
with website_sale and website_forum;
Some features may not be completely working as other tasks will continue to
improve the display, notably new slide display [1], some forum / slide
link improvements [3] and certification integration [4]. Some code cleaning
will come in future update as this merge allows to unblock those other tasks.
For more details see sub commits. And thanks to the RD Fun SM Team. Much
fun, much SM.
[1] main eLearning task: task ID 1902304 - PR #29876
[2] new user profile /gamification: task ID 1922159 - PR #30514
[3] forum and comments upgrade: task ID 1940516 - PR #30514 and #31097
[4] certification inside eLearning: task ID 1940360 - PR #31060
Purpose of this commit is to add the forum tab in course main new page
when the course is linked to a forum. Some demo data are added.
Some more work to better include forums and courses are ongoing [1].
This commit is linked to task ID 1936153 and PR #30770.
[1] forum and comments upgrade: task ID 1940516 - PR #30514 and #31097
Pimp my demo data. Purpose is to have some additional informations on demo
data defined in bridge module sale / slides. This one notably defines
a payment-based channel.
This commit is linked to task ID 1936153 and PR #30770.
Purpose of this commit is to effectively support payment channels in the
new channel homepage. Specifications
* display a 'Buy Course' button on payment based channels;
* redirect to eCommerce;
* display price;
We used everything available from eCommerce and product configurator to
find a real price to display. I must say I am quite happy with it.
This commit is linked to task ID 1936153 and PR #30770.
Co-Authored-By: Aurélien Warnon <awa@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Purpose of this commit is to rewrite slides demo data. More channels, more
slides, more images, less Odoo oriented content.
Everything is still not completely clean but at least it begins to look like
something we could show to people. Thanks to @awa-odoo who gave some demo
data. No thanks to @xmo-odoo who did not give demo data about the emu war.
This commit is linked to task ID 1936153 and PR #30770.
Co-Authored-By: Aurélien Warnon <awa@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
This commit proposes a new homepage for slides module evolving towards
an eLearning platform. It includes
* a new main page displaying top courses / channels. It displays 3 most
popular and newest channels as well as its ongoing courses (if logged).
Achievements and karma update done by eLearning community allow to give
a gamification look and feel;
* an 'All' page displaying all courses / channels. Tag groups and tags
allow to search / filter displayed courses;
* a new pimped and revamped display for main course / channel page;
For more details about specifications, send an email to aware people that
will be able to send you mockups. Or see the related task. Thanks to
@qmo-odoo who helped developing this homepage based on its work.
This commit is linked to task ID 1936153 and PR #30770.
Co-Authored-By: qmo-odoo <qmo@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
This commit squashes several fixes / light improvements related to the new
slides / elearning homepage [1][2].
Containing notably
* clean promote strategy field on channel model: less entries as they
are now used only to display lessons in a given order on channels of
documentation type;
* remove promotional fields, not used anymore since partial access on channel
allowing to have some kind of small preview of slides has been removed;
* use standard image field (image, image_medium and image_small) and use
image_resize_image from tools like all other odoo applications;
* improve image resizing to have medium images better looking on frontend
and use that nice image_large that broke my build yesterday;
* add last publication date change on channel;
* clean dead code;
[1] new homepage task: ID 1936153 and PR #30770
[1] main elearning task: ID 1902304 and PR #29876
Co-Authored-By: Aurélien Warnon <awa@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Purpose of this commit is to add challenges related to slide / elearning
module. 5 new challenges with their badges are added. Portal user partner
is now also published to have bioutifoul demo data. Commit linked to
eLearning tasks [1][2]
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
[1] new homepage task: ID 1936153 and PR #30770
[2] new user profile / gamification task: ID 1922159 and PR #30514 and #30988
Purpose of this commit is to give a specific route to access users image
used as avatar in profile and various frontend applications.
Indeed current web/image controller basically checks record access rights
with current user. However in some cases we want to display user avatars
even if current user cannot read user records, which is generally the case.
Indeed res.users is a private and technical model.
To solve that issue we add a controller for avatar. Basically published
and frontend active user avatars are available.
This commit is linked to task ID 1936153 and PR #30770.
When website_rating is installed, all frontend chatter will have
the string 'false' by default in the composer. This commit fixes
that, restoring the placeholder
closesodoo/odoo#31097
With this commit, the user can activate review on channel content when
creating a channel from frontend, or editing it from backend. Once
activated, the comment tab below the slide content will allow user
to post a comment with optional rating.
The way of commenting is different regarding channel type:
- documentation: user can post comment and vote (list/dislike) on
slide content
- training: user can post comment with review (rating)
Task-1902304
Before this commit, the user can only create a webpage slide
by setting its name, category and tags. On the channel grid,
no tumbnail was shown.
This commit allow the user to upload a cover image from the
slide upload modal and to modify it from form view. the
mimetype of webpage slide is now 'forced' through the
modal to 'text/html' to avoid conflit with 'image/png'
when setting the cover image.
Task-1902304
The view has been rewritten from scratch so the doc and the RNG validation
needed to be adapted.
Co-authored-by: dmo-odoo <dmo@odoo.com>
Co-authored-by: aab-odoo <aab@odoo.com>
Co-authored-by: jat-odoo <jat@odoo.com>
See odoo/enterprise#3437
Task 1856235
Issue: wysiwyg asset slow down the loading of the website, error
inadvertently introduced: https://github.com/odoo/odoo/pull/29775
The assets are now loaded assynchroneously, when the editor is needed,
its assets will be loaded.
closesodoo/odoo#30700
* = account, purchase, website_sale_comparison, website_sale_wishlist
Raw Image & Mixin
=================
Previously, the main image from a product was stored resized. This caused
inconsistencies with the size of the images on ecommerce: the main image was
resized, but the extra images were not.
Now, we always store all raw images, thanks to the new mixin. This way, product
images that were created before the installation of ecommerce will be ready to
be used in ecommerce without any other change.
We also store the resized versions instead of computing them on the fly: this
will take more disk space, but significantly increase the speed of the
pages when displaying images, as well as reduce server CPU load.
Images on variants
==================
Previously, it was only possible to set the extra product images on a template,
and not on a variant.
Now, we allow extra images also on the variants, this gives more flexibility to
the user.
Both extra images on template and variant have been given a sequence field to be
able to sort them easily.
On /shop we always display the image of the template for performance reasons.
On /product we never display the image of the template, unless the variant has
no image, then the template image is the fallback.
Carousel
========
The carousel view has been cleaned and improved:
- remove the duplicate XML that was created with the product configurator fix
- use a single loop from a single source to get all the images, instead of
merging the different sources in the view with complex conditions
- improve the HTML structure, reduce the CSS with appropriate classes
Preview Image
=============
Both in website and backend: make better use of `preview_image` to display
a small image whenever possible, to reduce download size for the end user.
task-34045
PR: #30656
Co-authored-by: Parth Gajjar <pga@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Add support for a 256*256 image, to be used in the following commit.
Define sizes in named variables instead of being hard-coded in several places in
the code.
Allow parameters `preserve_aspect_ratio` and `upper_limit` to be passed from
the different helper methods.
Factorize the code inside `image_resize_images` to make it easier to read.
Add new function to compute whether the size of an image is above a given size.
task-34045
PR: #30656
With this option we can define which field is going to be displayed by the qweb
image widget, while logic is still applied to the original field.
For example, we want to show a thumbnail image but when user updates it with the
web editor, we want to update the actual field instead of the thumbnail field.
This is similar to the preview_image of the JS image widget.
task-34045
PR: #30656
[IMP] hr_*: introduce the employee profile
================================
## 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. The Profile will show the employee of the current company.
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.
## Changed modules
### hr_attendance
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 hour.
-> The status is accurate on the report view (status is still updated
when loading the view)
-> The status in accurate at 1 hour on the kanban view
### [ADD] hr_attendance_presence
Bridge module between `hr_attendance` and `hr_presence`.
This PR 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
[ADD] hr_skills: Introduce a new module for employee resumé and skills
=======================================================
Purpose
-----------
Consultancy companies need resumé and skills of their consultants.
For big projects, they often need to send them to their customers.
These information are also useful to statistics.
Specification
-----------------
### New models
#### `hr.resume.line.type`
Types of resumé lines. e.g. *Experience*, *Education*, *Hobbies*
#### `hr.resume.line`
It is a line in the resumé of an employee.
#### `hr.skill`
Name of a skill. e.g *French*, *Python*, *Piano*
#### `hr.skill.type`
Skills can belongs to a particular type. A skill type has skill levels associated.
e.g. *Languages*, *Dev*, *Music*
#### `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%)*
#### `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.
[IMP] hr, hr_holidays, hr_expense: Change onchange parent_id behaviour
=========================================================
Purpose
-----------
When the manager (parent_id) of an employee changes, it doesn't always mean that other responsibles (Leave responsible, expense responsible, coach) should also change.
Specification
-----------------
When changing the employee's manager, the leave responsible, the expense responsible and the coach should be changed only if the field was not set or if the responsible is the previous manager. In that case, they should be set to the new manager. Otherwise, it means the field was most probably set manually and it should be left unchanged.
Task 1913089
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#30502
When a new allocation is requested from the leave dashboard,
the page is not reloaded. Therefore the displayed data is not
up to date with the new allocation count.
This commit makes the page reload after each new allocation.
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.
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
Before this rev., it was possible to specify default values for
categories (fields with attribute select="one") in the context
(e.g. searchpanel_default_fieldname: 5). It is now possible to
specify default values for filters (select="multi") as well
(e.g. searchpanel_default_fieldname: [1,2]).
closesodoo/odoo#31107
Task #1940360
Subtask of #1902304
Purpose
=======
Slide views made by non-members of the channel (typically the website_publisher
designing the survey) should be counted in the "public_views".
closesodoo/odoo#31096
Only search once for batch of moves that should be assign
to the same picking and assign them all at once.
Since the moves are processed in batch for a picking
commit 8fe8ca9 is not needed anymore.
closesodoo/odoo#30699
Production order are created in batch. Confirm them and
create their componenets moves in batch also. Adapt _get_moves_raw_values
method in order to be multi. action_confirm was already multi.
Usecase to reproduce:
- Product with routes MTO and BUY
- Add a supplier on a product with a min qty of 5
- Create a SO with a qty of 1
A PO is created with the supplier and a quantity of 1. It should return
an error since there is no suppliers that sell with this quantity.
It happens because _run_buy directly use the suppliers on the product
without check for date and minimal quantity.
This commit replace it by _select_seller that manage every details.
Improve the procurement requests performance. Instead of processing
procurement request one by one, search rules that apply for each of
them and group them by rule's actions.
The main technical change is the record creation order.
E.g. 2 SO lines with pick ship delivery.
-Before this commit:
line1 -> LAUNCH_RULE -> PICK MOVE1 -> MOVE1 CONFIRM -> OUT MOVE1
line2 -> LAUNCH RULE -> PICK MOVE2 -> MOVE2 CONFIRM -> OUT MOVE2
-After this commit:
line1/2 -> LAUNCH RULE -> PICK MOVE1/2 -> MOVE1/2 CONFIRM -> OUT MOVE1/2
Also there is one batch creation by company_id. It implies that values
are group by company_id. Since company_id are passed by previous
procurement or by the rule, it become a required value and it's added to
the procurement arguments (it was already always passed in the values,
no functional modification).
_run_buy is reworked. It receives a bathc of procurements, those
procurements could be merged in the same PO or the same PO lines.
However the PO/PO lines are created (if procurement couldn't be
merged in an existing one) at the end of the method. It implies
that 2 procurements creating a PO and merged inside, would now create
2 distinct PO (same for po lines). _run_buy in order to fix this issue:
- group procurements by PO search domain. If the PO doesn't exist,
create only one.
- Inside the same PO: merge quantities, move_dest_ids for procurements
with the same product and UoM.
Other _run_ methods are just adjusted in order to process batch.
For a pick pack ship scenario, without procurment_jit confirm a SO
containing 500 lines will take 40s instead of 15 minutes.
Purpose
=======
Currently fields with a `groups` attribute can't be tracked.
Otherwise changes would be visible by all in the chatter, including
users which normally don't have the access rights because they are
not members of `groups`.
Specification
=============
Filter tracking field values according to the `groups` attributes.
Users without the access rights should not see them.
If a message is only composed of tracking values and the user doesn't
have the rights to see them, an empty message should not be displayed.
Purpose
=======
When the manager (parent_id) of an employee changes,
it doesn't always mean that other responsibles (Leave responsible,
expense responsible, coach) should also change.
Specification
=============
When changing the employee's manager, the leave responsible,
the expense responsible and the coach should be changed only
if the field was not set or if the responsible is the previous manager.
In that case, they should be set to the new manager.
Otherwise, it means the field was most probably set manually and
it should be left unchanged.
The purpose to set orderpoint_id on MO is to keep the behavior than
purchase_order. It's also a future work for procurement in batch because
after creating a production order, a note is posted with its origin.
Since orderpoint_id was not set on the MO, we would have to keep all
procurements values dict after MO creation and rematch them in order to
log the note with the origin.
Currently when the payment is initiated there is a message in
sale order for waiting for confirmation.
But when the payment returns an error there is no message on
sales order so it's not clear for the end user that payment
is still pending.
Related Task ID : 58741
jem-odoo