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
=======
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.
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
As gamification karma-based features can be used outside of forum let us
move demo and data directly in gamification. It will be used notably for
eLearning.
This merge provides new modal to create slide channel from the 'New' website
menu, like blogpost or forum. It also improves the upload slide widget from
channel homepage.
This merge also brings new slide type 'webpage'. This allow user to create
completely customized content as a slide.
This merge is linked to Task-1938643. More generally it is linked to the
eLearning feature [1]. For more details see subcommits.
[1] see task ID 1902304 (main eLearning task) PR #29876closesodoo/odoo#30991
With new slide type, it was required to change the
upload modaL. Now, the use select first the type
of document he wants to upload, then the correct
form appears. When filled, user can sumbit it to
be redirect to the slide he just create.
Task-1938643
The idea is a slide can be a HTML page completely customized by
user. So, you can now easily create custom content and publish
it on your website, like a normal slide.
Task-1938643
Having a unique constraint for a slide name in a channel look strange.
It force an RPC call to check this when uploading a slide, making the
process a little bit slow.
Morevover, name is a translatable field on slide.slide model, so the
constraint can not be fully respected.
To simplify the model, we decided to remove this.
Task-1938643
A slide can now have some external link. For instance, links to
the origin of the document (sources for scientifics papers, ...).
A new model is added to allow the user to provide several link
per slide. Those are display below the channel on website page.
Task-1938643
This commit provides the abilty to create channel from the website
instead of creating a slide. To do so, the user still have the "upload"
button on the channel home page.
The new modal allow user to set title, description, type and channel
tags. We prevent channel tag and group tag creation on the fly, as it
can impact the UI (coming in a future commits).
Task-1938643
This commit changes some methods so they can be used in the account_documents enterprise bridge
and adapts activity tests for the new request on upload_file feature.
task: #1928404
related to: odoo/enterprise#3607closesodoo/odoo#30950
Task #1937160
Purpose
=======
Performance improvement:
The members_count computed field now uses a compute_sudo with
a read_group allowing to compute all the members_count of the recordset
in a single query.
closesodoo/odoo#31013
3bf8e75379 changes the only call to
has_delivery to a check on another variable. This commit removes
the field from the model as it's now useless.
Task : 1908654
closesodoo/odoo#28976
On a sale order, the delivery carrier choice was done directly
on the form view. To get an estimated delivery price, the user need to
click 'add to order' to create a delivery fee line. To get the exact
delivery price on the sale order, the user needed to leave the sale
order without delivery line in order to get the exact price from the
picking at its validation.
As this flow was not so clear, this commit adds a new wizard to choose
the delivery carrier and check its commition fees. This add a line in
any case.
The wizard will be launched from a new button on the sale order
Task : 1908654
The delivery carriers get a new field to specify the invoicing
policy. The two cases are :
- Estimated cost: the delivery price is charged directly on
the sale order based on the estimated fee
- Real cost: the delivery price is estimated from the sale order
but not added in the delivery line (we get a line with quantity=1 and price = 0).
Once the delivery is validated, the delivery price is recomputed.
The new price depends on the integration level. If it's 'rate', the price is
the estimated one (carrier.rate_shipment()). If it's 'rate_and_ship, the price
is the one given by the carrier at the delivery
The bases carriers (fixed_on_rule and base) always use 'Estimated Cost'
as their price should not be changed between the sale order creation
and delivery validation
Task : 1908654
Purpose of this merge is to be able to sell courses [1] when using the
slides / eLearning platform.
This commit adds sale capabilities on a slide.channel. A slide.channel can
now have the 'payment' visibility, that requires a 'product_id' configured
on the channel.
When a customer purchases a product linked to a channel, he is added to the
members of the channel (see slide.channel.partner_ids) when his order is
confirmed.
This merge is linked to task ID 1937160 and PR #30914. Future tasks will
improve homepage of channels and clearly show public, private and payment
based channels [2].
[1] see task ID 1902304 (main eLearning task) PR #29876;
[2] see task ID 1936153 (new homepage for slides) PR #30770;
Purpose
=======
With the new 'website_slides_sale' module users can now sell slide.channels.
This commit adds a setting to let the user know he has to install website_sale
to be able to sell courses / documentation.
Purpose
=======
Currently, the slide_channels having a visibility configured as 'invite' could
only add members manually.
This commit adds an 'Invite' button on top of the slide channel form that opens
a wizard allowing to send emails to contacts and also make them members of the
related slide channel.
Task #1937160
Purpose
=======
This commit adds a "Attendees" stat button on the slide.channel form view
showing the members (partner_ids) count.
On click, it redirects to a tree view of slide.channel.partner. The tree
view is configured as editable to be able to administrate members
(add/update/delete).
Task #1937160
Purpose
=======
This commit adds sale capabilities to a slide.channel. A slide.channel can
now have the 'payment' visibility, that requires a 'product_id' configured
on the channel.
When a customer purchases a product linked to a channel, he is added to the
members of the channel (see slide.channel.partner_ids) when his order is
confirmed.
The feature is added in a new module 'website_sale_slides' that comes as a
bridge auto-installed between 'website_slides' and 'website_sale'.
The final goal is to be able to sell "courses" (see task #1902304).
Purpose of this merge is to prepare eLearning feature by already modifying
channel model.
It includes
* addition of tag and tag groups on channel, allowing to filter and search;
* addition of statistics computation on channel, notably tracking completion
of users;
* removal of promoted slide feature and addition of specific image field
on channel;
This merge is related to task ID 1936153 and closes PR #30985. More
generally this merge is linked to ongoing tasks
* task ID 1902304 (main eLearning task) PR #29876;
* task ID 1922159 (new user profile and gamification) PR #30514;
* task ID 1937160 (payment flow and integration with ecommerce) PR #30914;
*: base, bus, mail_bot, test_mail
Before this task, it was not easy to tell when a user is not available (or is on holiday)
from conversations, such as from chat windows.
With this task, a user can now tell that he is out-of-office from the user menu preferences,
by defining an an out-of-office message. This information will be displayed to other users from
chat conversations and mention suggestions (i.e. with `@`).
Also, the computation of the user `im_status` has been changed when he has an active leave:
an out-of-office message can be set on the leave, and this will be displayed on conversations
instead of the user's out-of-office message from the user menu preferences.
Task: 1856205
closesodoo/odoo#29974
Task #1908673
Purpose
=======
The "invoice" modal is too complex to use for new users and has a lot of useless options for
the most simple use cases.
The goal here is to remove 2 options of the 'advance_payment_method' field:
* Invoiceable lines
* Invoiceable lines (deduct down payments)
And combine them into a new one: "Standard invoice".
If there are any down payments to deduct, another checkbox field appears under this
one: "Deduct down payments".
This keeps all the invoicing features while simplifying the modal.
Spec
=======
* Remove "invoiceable lines, deduct down payment" and replace by a checkbox
(checked by default, only visible if down payments to deduct)
* Rename "Invoiceable lines" into "Standard invoice"
* tooltip on radio buttons: A standard invoice is issued with all the order lines ready for invoicing,
according to their invoicing policy (based on ordered quantity or on delivered quantity).
closesodoo/odoo#29978
Purpose of this commit is to clean a bit channel model. Promoted slide
feature is removed as people can already choose an order for a given
channel. Moreover promoted slide will not be used when having a eLearning
display of a channel.
Image field on channels is added as it is not depending on promoted slide
anymore.
To simplify future additions a search-specific template is removed to
have a unique template to display a channel content. It will ease future
merge.
This commit is linked to task ID 1936153 and PR #30985.
Purpose of this commit is to add some statistics computation on slide.channel
model. We want notably to have a count of views and votes (likes and dislikes)
on channels. Completion is also computed.
Purpose is to be able to search and order channels based on those statistics.
Having stored computed fields for some statistics help achieving that purpose.
Tests are added.
This commit is linked to task ID 1936153 and PR #30985.
Purpose is to be able to filter, search and categorize channels. Notably
with eLearning in mind there will be more channels as a channel will also be
used to hold lessons.
For that purpose we add a model of tag linked to channels. Those tags are
organized by groups in order to be able to display them using a menu or
a small hierarchy of tags. Displaying a tag group as a specific navigation
element is controlled by a specific field.
Those models will be used to display a new and improved home page for
channels / courses.
This commit is linked to task ID 1936153 and PR #30985.
`channel_info` can be called on multiple channels especially during
the init_messaging. The current implementation will perform read and
other queries in the loop. This commits aims to refactor `channel_info`
in order to read all informations in database out of the loop.
Computation of members informations is now the same as for `direct_partner`
As a side effect direct partner will have an email adress and members will have
im_status and out_of_office message if the partner is in a
channel of type chat. It would be easier to compute im_status in all case but
this could create performances issues when calling channel info on channel with
hundreds of users.
channel_fetch_preview will make a query in database in any case but seems to work ok
in api multi. We can put it out of the loop.
44ac7903cc fix shouldn't be broken by this refactoring since we are no longer using the many2many to find direct_partners.
The IAP logo is an svg file, and contains a text tags with font
specified in it. It leads to wrong display in some browser and/or
operating systems when the font is not installed.
To avoid this wrong display we changed the text into a path in the svg.
closesodoo/odoo#30995
Task #1908673
Purpose
=======
The "invoice" modal is too complex to use for new users and has a lot of useless options for
the most simple use cases.
The goal here is to remove 2 options of the 'advance_payment_method' field:
* Invoiceable lines
* Invoiceable lines (deduct down payments)
And combine them into a new one: "Standard invoice".
If there are any down payments to deduct, another checkbox field appears under this
one: "Deduct down payments".
This keeps all the invoicing features while simplifying the modal.
Spec
=======
* Remove "invoiceable lines, deduct down payment" and replace by a checkbox
(checked by default, only visible if down payments to deduct)
* Rename "Invoiceable lines" into "Standard invoice"
* tooltip on radio buttons: A standard invoice is issued with all the order lines ready for invoicing,
according to their invoicing policy (based on ordered quantity or on delivered quantity).
Purpose
=======
The method named "action_invoice_create" in the sale_order model did not make sense:
- this method is not an action (it returns the ids of created invoices)
- it is not used as an action on any xml buttons
- it has no reason to be private
This was probably a "real" action somewhere in the past but now it's just too confusing.
(The method in repair.order was also renamed for the same reasons).
Improve the User Interface of the Calendar mobile view.
- The "today" button should be aligned (both size and position) with the
view switcher icon.
- Extract mobile calendar styling into dedicated SCSS file.
Task ID: 1891955
closesodoo/odoo#30592
Lucas Lefèvre