Purpose
=======
Ease modification/addition of views and actions (in particular
when inheriting actions in hr_holidays_gantt)
Specification
=============
Use `form_view_ref` in the action context
instead of the form xml id in all views.
+ Add tree view from "Time Off / My Team"
Social secretariat is a Belgian concept. It does not make
sense to have this in the standard contract app.
Will be reintroduced in l10n_be_hr_payroll (or internal)
if really needed.
Move `job_id` in the right group to easily add fields
on the right with view inheritance.
Purpose
=======
When a leave is created and approved, it can also create
a meeting in the calendar. In the leave type configuration
a particular meeting type can be chosen.
The purpose is to simplify this.
Specification
=============
Remove the choice of meeting type.
The choice should be:
Display Leaves in calendar: Yes/No (checkox)
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.
TaskID: 1961151
closesodoo/odoo#33725
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
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.
In List View, the Import button is placed after the Create button.
Before this commit, in a list editable in edit mode, the Create button
is hidden and the Save & Discard buttons are displayed.
But as the Create button was placed before the Save button, the Import
button will appear at the first position.
With this commit, the Create button is now placed after the Discard
button. In this way the Import button will be always the last button and
its position will not change when we switch between edit and read modes.
closesodoo/odoo#32613
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this commit, we had two form views for production lot: one more
complete and one simplier.
The complete one was displayed when we come from the prod lot list view,
and the simplier one in any other case.
But actually, we need to display the simplier one only with "Create and
Edit" and display the complete one in any other case, but it's
impossible to do with only two distinguish views.
So, we keep only one view with all elements and we display or hide some
fields or button in function of the context or if the record is new.
Task #1935921
Creation of a js_class: singleton_list.
It's used in the quant list view and its purpose is to avoid duplicate
line in list editable.
When user creates a new record, if the server responses with a ID
corresponding to a record already present in the view, it'll update the
old one instead of create a duplicate line.
Task #1935921
Change the use of Inventory Adjustment, notable changes are:
- Removed filter field: When user creates a new inventory
adjustment, he can set one or multiple locations and/or products.
An inventory adjustment will worry only about defined
locations/products, but if neither product or location was set,
it'll manage all stock.
- Inventory Adjustment Lines have their own view instead of be
listed on the Inventory Adjustment form view.
Inventory adjustment lines have new color legend:
- Red: The quantity is outdated.
- Blue: There is difference between the on hand quantity and the
counted quantity.
New inventory lines created by the user are written in bold.
- User can't modify already existing inventory lines, except for the
counted quantity.
- When an inventory line is outdated, the user has the possibility
to select and update it, that'll recompute the on hand quantity.
- When an inventory adjustment is validated, it will take in account
only the difference between the theoretical quantity ('On Hand
Quantity') and the counted quantity to adjust the quants.
- When an inventory adjustment is canceled, it will keep its
inventory lines and won't regenerate them when re-started.
- When an Inventory Adjustment generates Account Moves, user can now
find them in a stat button in the Inventory Adjustment form view.
Also, made some changes in demo data to match new requirement.
Task #1935921
Made some changes in stock.quant model to allow user to modify product
quantity easier.
To allow the edition of quant without opening more permissions on the
model, we switch to sudo in create mode and write if the conditions are
met (special key in context + access rights on the current user + write
on a specific field).
Also, we have two list views for the quant:
- The old list view who still readonly.
- A new list view where user can create new quant or edit quantity
of existing ones
We display the second one if user is a stock manager.
For existing quants, user can modify counted quantity (which will modify
product quantity). User can also create new quant, in this case:
- The quant is really a new one (ex.: new product/location
association) so will simply create a new quant.
- A corresponding quant already exist, so will modify the existing
quant instead of create a new one.
When an user creates a new quant, the model will check each time a
non-quantity field (product, location, SN/LN, package or owner) is
modified to see if corresponding quant exists. In this case, it'll get
the quant ID and will update reserved and on hand quantities.
If user didn't change the inventory quantity, it'll be updated too.
On product form view, the 'Update quantity' button was removed as user
can now simply modify quant with 'On Hand' stat button.
Task #1935921
Co-authored-by: sle-odoo <sle@odoo.com>
Purpose of this merge is to clean and improve performances of post and
notification mechanism contained in mail application.
In this merge we provide
* centralization of notification code inside mail.thread instead of being
dispatched in mail.thread, mail.message and res.partner;
* simplification of call chain, removal of unnecessary methods;
* better propagation of messages value through the various calls in order
to use given value and avoid browse and cache miss adding queries;
* optimization of attachments management in post;
* cleaning of message_post now limited to records and simplified in its
management of parameter;
* cleaning and simplification of recipients grouping for email notification;
* cleaning of message_notify;
* various code cleaning and tweaking in order to reduce query count;
Performance tests indicate number of queries did fall, especially in
use cases involving management of followers and attachments. See sub
commits for more details. This merge is linked to task ID 1943901.
closesodoo/odoo#32404
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since ORM changes, the ids a many2many are new (virtual) ones in a
onchange, so we have to point to origin which are the real records to
check that the many2one is in as it has a real id.
closesodoo/odoo#33763
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Currently the fact that the changes in the expected dates are propagated
or not is based on :
- the value of the field propagate on the stock.rule
- the general inventory setting setting use_propagation_minimum_delta
That's not easy to understand for users and difficult to configure.
The purpose of this task is to clarify this configuration (everything is configured
at the same place + but we keep the flexibility by setting this config on the stock.rule)
task-1913401
closesodoo/odoo#33719
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
We use a new method to connect the box to a device in the network.
We use the socket to listen a specific port in the box to connect device through the TCP/IP
Task: 1891152
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#33398
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
This commit improve the display of payments lines and give
a name to last notebook group in /addons/point_of_sale/views/account_statement_view.xml
to be able to override it in enterprise
With this commit it is now possible for the IoT Box
to listen on a specific port of the box to interact
with a device via TCP / IP.
We use the library 'socket' to listen on port 9000
and if a request comes on this port we create an IoT Device
Purpose of this commit is to improve performance of post and notify through
various code improvements.
Containing
* making of _notify_customize_recipients a mail.thread method;
* _message_auto_subscribe_followers optimized;
* renaming and optimisation of _notify_partners;
* message_post_attachements optization;
* remove unused mail_post_autofollow_partner_ids context key;
* minimize message create queries;
* only check record related access right for thread messages not in pending
moderation;
* get attachements from values instead of db;
* storing lang in ctx from the beginning;
* don't track on write on attachments;
Related to task 1943901
Linked to PR #32404
Purpose is to make field use more obvious by correctly stating in the
name it should contain an xml id to a qweb layout used for email
notifications. This renaming is propagated through various calls and
addons.
Related to task 1943901
Linked to PR #32404
Purpose of this commit is to clean notification process: calls, methods
API, method name, variable propagation.
Contains notably
* simplify API of methods used to group recipients when sending notification
emails;
* improve and rename methods used in email notification process;
* move some methods on model itself as non mail thread records could be
mass-mailed and _notify_email_headers could be called on other records;
Related to task 1943901
Linked to PR #32404
If no email layout is found when trying to render the layout around the
message content, just send body in notification emails instead of
crashing. See notably 89051058f4 .
Related to task 1943901
Linked to PR #32404
Purpose of this commit is to move notification methods to mail.thread. Indeed
currently they are split among several models: thread, message, partner.
It makes code difficult to understand. Base record has to be propagated in
order to run methods on it. It is therefore simpler to make those methods
on mail.thread and correctly have model methods.
All notification methods are moved into a single section in the mail.thread
file. This implies some more code move inside mail.thread but allow to have
methods classified by their purpose.
Related to task 1943901
Linked to PR #32404
Message post should always be called on a record (ensure_one). That way we
ensure posting a message is always done in a record's context with right
values computed (reply_to, followers, ...)
Message_notify can be called on record or on mail_thread and must have
partner_ids. It is based on the recently modified user_notification mechanism
and allow to notify a partner on a record or just to push him a message
(aka, not linked to a record).
Small performance improvement
* browse recipients instead of search in _notify_email_recipients;
* todo in future optimizations: mayybe be improve by searching on ids
and is_blacklist immediately;
Related to task 1943901
Linked to PR #32404
Purpose of this commit is to clean some bits of code, notably calls to
message_post/log as well as notification methods. It will ease performance
improvement work.
Small optimization: account: read content after extension check
Parameter cleaning
* use message log with kwargs instead of args;
* remove message post after hook useless parameters;
* remove _notify_email_recipients useless message parameter;
* remove message_notify useless send_after_commit parameters;
* remove message post params matching default values;
Other improvements
* remove message_post commands support for partners and channels;
* only calls message_post with ids list for channels and partners. We
don't support mix of ids and command anymore to simplify code;
* remove support of private discussion in mail.thread adding partners
as recipients, as there is no use anymore;
Related to task 1943901
Linked to PR #32404
It includes notification on inbox / email as well as attachments management.
This latter one adds quite a lot of queries and is not currently tested
for performances. Future commits will improve those counters.
Related to task 1943901
Linked to PR #32404
Currently if a message has a res_id and a res_model it appears in the
matching record's chatter. Its access rights are computed based on this
record. This is the standard behavior of mail.message model.
User notifications are currently built on messages not having model and
res_id in order to avoid appearing on chatter. This has several drawbacks
notably access rights, redirection to the record, systray, finding back
records, ...
This commit solves those issues by adding new message_type 'user_notification'
that should be as a classic mail.message with model and res_id but without
the whole notification mechanism and without being displayed in the chatter.
An user notification is now a classic message pushed to a given partner only
and not displayed in the chatter.
Related to task 1943901
Linked to PR #32404
Implement the propagation minimum delta per rule in purchase_stock. Override
properly the write to handle both RFQ and PO. Take care of not merging po lines
where the expecte date should be different
Add propre test cases.
task-1913401
This commit moves the "propagation minimum delta" from a company setting to a
per-rule setting.
We implement this idea in the stock module and take this opportunity to clean
up the override of stock move's write.
We add a few basics tests.
task-1913401
This commit relax, by one second, two datetimes comparison regarding
workorder planning to avoid any false positives
closesodoo/odoo#33740
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Lucas Lefèvre