| Age | Commit message (Collapse) | Author |
|---|
|
instead of 'contact'
Purpose of this task is,lots of business flows can be crashed if
the field Private Address(address_home_id) is a private address instead
of a regular contact.
so in this commit,we change the demo data for employee and set the
private type address on employee for private address and also fix
the flows on which errors could occur.
Currently billing administrator does not have right for private address
and while creating payment from expense it was going to set the
customer from the employee's private address on payment so give the
private address right to the billing adminnistrator.
Also chaned admin/demo user's private address as 'private' instead of
regular contact.
and on hr_expense use the Sudo while accessing the home address this
method is used from payslip too.
TaskID:2170016
closes odoo/odoo#46628
Closes: #46628
Related: odoo/enterprise#8924
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
PURPOSE
When incoming emails bounce due to alias security bounce email is quite
generic. Purpose of this task is to ease its customization and update.
SPECIFICATIONS
In order to improve the flexibility of alias, add a customizable html field
on the alias model. This html content will be send as bounce email core content
in case of bounced/unauthorized mail received for this alias,
Obviously it has no effect on 'everyone' security setting as no email will
bounce due to that issue.
If it is not set a default generic mail will be send depending on security
setting. It allows to keep void html fields when no specific bounce content
is required
In HR, an old template allowing some light customization for employee based
security option is removed as it is completely replaced by the new feature.
Also add references message-id of the mail received to the answer so that
threads are correctly set.
LINKS
Task ID 2126509
|
|
RATIONALE
Mail template model holds a field telling odoo mail engine to automatically
add the current user's signature to the body. Its use depends on the use
case
* using the template in the composer on a single record: it is displayed
in the rendered template in the composer, meaning people could change it.
This behavior is interesting as it allows to see the email content;
* using the template in the composer in mass mail mode: it is not displayed
as only the raw jinja is displayed. It is therefore not obvious that it
will be appended to the body of the mail. People could add it manually and
have 2 signatures as a result;
A mechanism automatically adding a signature to sent emails when posting a
message is already implemented and is based on template existence. If a
template has been used when posting, no signature is added in sent emails.
Otherwise it is automatically added. This behavior should not change.
Behavior will therefore be
* use a template -> specify signature usage in it manually through jinja;
* do not use a template -> signature added in sent emails;
SPECIFICATIONS
Remove user_signature.
Update template body accordingly. In customer oriented templates that are using
it and do not already contain it, manually add a call to user.signature within
the jinja code. When set to False, just remove its declaration.
Quickly clean some signature integration.
LINKS
Task ID 2089252
Community PR odoo/odoo#39482
Enterprise PR odoo/enterprise#6459
Upgrade PR odoo/upgrate#761
Related: odoo/enterprise#6459
Related: odoo/upgrade#761
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
|
|
The following models are already using big images, or they might need big images
in the future:
- partner
- hr employee
- shop category
- lunch product
- gamification badge and karma rank
PR: #34925
|
|
Purpose
=======
There are currently multiple ways to determine if an employee is presence
or absent:
- login state (user status on chat)
- checkin/checkout from the Attendance app
- leave
- hr_presence (email, ip)
Those states are displayed in several different places and can be inconsitent.
e.g. Logged in -> green in the chat
Not checked in -> red on the employee kanban view.
The multiple ways to determine employee presence described above
should be aggregated together to have a better consistency.
Specification
=============
There are 3 presence states (previously defined in module `hr_presence`),
namely `present`, `absent`, `to_define`. They are now defined as soon as
`hr` module is installed.
The state computation can have several behaviors according to which apps
are installed:
1. `hr` is installed
Check employee presence based on login by default (only for employees with
a user).
Kanban state (private and public): should be green when logged in, red when logged out and
orange when the user is away.
Private employee form: Display a stat button "Connected" on the form view
when the user is logged in or "Last Activity xx/xx/xxx" otherwise.
2. `hr_attendance` is installed:
when the user is logged out, the state
is determined from the checked in/out state. But when the user is logged in,
consider the user as present (even if he checked out).
Kanban state: green for checked in, red for checked out
Private form view: attendance stat button.
3. `hr_holidays` is installed:
Has the highest priority if the employee is on leave.
Kanban state: red if employee is on leave.
Private form view: stat button "Absent Until xx/xx/xxxx" if employee
is on leave.
4. `hr_presence` is installed:
Two additionnal presence checking option: emails sent and IP address connected.
Once a user sent an email or the IP address was connected, he is considered
present for the entire day.
There should be at most one stat button on the employee form view, with the
relevent information.
Task id: 2024482
closes odoo/odoo#34933
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
Purpose: use more email_formatted when possible, clean and simplify
email_from, email_to and partner_to computation.
Next step is to try to extract some common patterns in tools or methods in
order to simplify template creation and customization.
Related to task 1972615
Linked to PR #32872
|
|
Purpose of this merge is to avoid having to define custom activity types for
each step of HR onboarding plan. This is done by adding a summary field
on hr activities, allowing to use default Todo activity type and customize
directly the summary itself.
Using custom activity types is still possible. Here we allow to avoid noise
and having too much activity types defined as most of those activities can
be simulated using the default Todo.
People can still define and use their own activity types if necessary and
required in their daily workflow.
Commit linked to task ID 1923387 and PR #30235.
|
|
Purpose
=======
Give the possibility to elaborate plans through Odoo. For instance, in HR,
you could create an onboarding plan when a employee is created. Someone manages
laptop and other equipment, someone check hr stuff, ... This feature is generic
but in a first time we will apply it only on the hr module.
Ease HR process in a company by creating plans: a plan is an assembly of Next
Activities that will be launched together whenever you need it.
Example of plan for an employee onboarding:
Activity: Prepare materials
Responsible: Alain
Deadline: At the contract signature
Activity: Manage Cars
Responsible: Cécile
Deadline: at the contract signature (both signature)
Activity: Plan Training
Responsible: Caroline
Deadline: After signature
Activity: Training
Responsible: Employee
Deadline: 1 week after the employement date
Specifications
==============
On HR Configuration: Add a menu "Activity Plans"
Activity plan object:
- Name
- Model (debug mode) (hr by default)
- Activity Template o2m
- Activity Type (only the one related to hr)
- Deadline (come from Activity Type)
- Responsible \/
0 Coach
0 Manager
0 Other
[Responsible_name] \/ (coach, manager or manually set if other)
Add datas, 2 plans:
Onboarding
- Name: Onboarding
- Plan lines:
Activity: Setup IT Materials
Responsible: [a user] (manager)
Deadline: At the contract signature
Activity: Plan Training
Responsible: [manager]
Deadline: After signature
Activity: Training
Responsible: [Employee]
Deadline: 1 week after the employement date
Offboarding
- Name: Onboarding
- Plan lines:
Activity: Compute Out Delais
Responsible: [a user] (manager)
Deadline: today
Activity: Take Back HR Materials
Responsible: [manager]
Deadline: today
Activity: Manage Car
Responsible: [manager]
Deadline: today
When to trigger it ?
HR specific use case:
1/ On employee, from the employee chatter:
when you create an employee, Odoobot will log a note with the following message:
"Congratulations ! May i recommand you to setup an onboarding plan?", with a link
create a plan from it.
2/ Add a button 'launch plan' to open a wizard to select the plan
3/ When archive an employee
Open a wizard with:
- Reason (selection)
- Action plan (m2o not required)
Error if employee not linked to a user.
Task : 1912681
closes odoo/odoo#29151
|
|
User 1 simply becomes a technical user (inactive, no password).
|
|
[NEW] base: show enterprise module, with an 'upgrade' button
[IMP] *: some modules renaming, and improved copywriting of manifest
[IMP] *: utm on links to odoo.com
|
|
In this commit we improve templates used in hr. Purpose of this commit
is to have templates that embed or use standard Odoo email layouts to make
them look modern and have a common style across all emails.
Main guidelines
* better use of div / p / br to try to lessen layout issues, especially
when updating templates using the editor;
* correctly sequence the templates fields definition;
* correctly set templates values notably auto_delete and user_signature
fields to avoid confusion;
* correctly layout the email content using light notification email. It
can either propagate the layout choice through various send mail methods
or directly embed the styling in the templates for more technical or
complex templates;
* use email_formatted computed field when possible to avoid having hand-made
from / to addresses;
* fix various typos and improve subjects when necessary;
Content of emails is not necessarily updated as the purpose of this task is
about styling, not content itself.
This commit is linked to task ID 1843361 (and 1868112) and to PR #25299
(and #25889).
|
|
|
|
New feature in mail module
==========================
Currently, an email can be sent to an alias from:
- Everyone
- Authenticated Partners
- Followers
This commit is intended to add another category: Employees
The main purpose of this new feature is to allow employees to send an email
to an 'expense' alias in order to create automatically their expenses with
their mobile phones.
Use this new mechanism in hr_expense
====================================
Currenlty, we're overriding message_new to make a security check and create
an expense if the sender is an employee or bounce otherwise, which is not the
correct way to achieve this. A better way is to use the alias mechanism now
that it has been extended to employees too.
Don't hardcode email_from
=========================
The email_from of the bounce email is hardcoded to "help@odoo.com". I am sure
they will be happy to receive all answers from any odoo instance
Review the bounce email content
===============================
content: Your expense has not been created because your email address is not set
on an employee or on a employee's user. Configure your employee's information correctly and try again.
-> this is a message for the admin, not an employee or anyone else
Now the content is generical for aliase defined for employees.
|
|
addendum to commit da6b9d1be443999028f021ff81b4cf128a4eaaa2
- better employee name and image for default employee in data (xml-id: hr.employee_root)
- in demo data hr.employee_fp renamed to hr.employee_root to not have 2 employees linked to the root user
- renamed all occurences of employee_fp to employee_root
|
|
Replace employee linked to base.user_root (administator) in data
by employee_fp (Pieter Parker) from demo data in order to avoid having 2
employees linked to the root user.
|
|
|
|
- Rewrite the code to new api without changes
business behavior
- Remove old v7 backward compatibility method
- Regroup view definitions in the same xml file
- Use read_group for computed fields
|
|
|
