Daily updates from Odoo
Navigate
Branch
Thursday, August 26, 2021
10 changes
New functionality added to Odoo
Portal users can now access shared project task views for field service, helpdesk, sales, worksheets, and reporting with controlled visibility and editing. This improves external collaboration while limiting access to approved task details, messages, timesheets, materials, and worksheets.
Original PR description
Purpose ====== Adding the project sharing feature. This feature consists to share the backend views of `project.task` model to portal users. The difference between the classic backend views and the…
Purpose ====== Adding the project sharing feature. This feature consists to share the backend views of `project.task` model to portal users. The difference between the classic backend views and the project sharing views is in the project sharing views, we list the fields that the user can read/write, so the portal users can see only the fields in our list. Moreover, the actions and the contextual menu (actions dropdown) are not available in the project sharing views and the stat buttons are visible but the click on these buttons are disabled. Implementation details: ================= - override the project sharing webclient to support the mobile devices. - override the views in the different views using the project.task model to have add feature in the project sharing but with a restrict access. - add the chatter in the `project.task` form for the portal user. This user could send message and see the public messages if this portal has either 'Comment' or 'Edit' access right of the shared project. task-2379518 Community PR: odoo/odoo#73341 Upgrade PR: odoo/upgrade#2621
Enhancements to existing features
Gantt views can now group records by fields that allow multiple linked people or items, such as tasks with several collaborators. This makes planning and workload views more flexible because the same task can appear under each relevant group, and new records keep the correct multi-person assignment.
Original PR description
PURPOSE Allow to group records by many2many fields. Use case: turn the user_id m2o field on project.task into a user_ids m2m field in order to assign multiple collaborators on a task SPECIFICATION Add many2many fields to the 'list of groupable fields': gantt TASK 2508608 COMMUNITY PR: odoo/odoo#74985
Manufacturing reports now provide clearer production cost trends over time and better account for by-products when calculating costs. Cost reports also handle exchange rates correctly in multi-company and multi-currency setups, helping teams make more reliable margin and production decisions.
Original PR description
This PR does multiple things: 1. Improve overall MRP reporting by: - adding a new MRP (SQL) report that focuses on production costs over time for a product - hides useless `worksheet_page` measure for "reporting > Work Orders" 2. Adds enterprise support for new by-product "cost share" for a MO (i.e. update existing cost reports to correctly take them into account), which includes: - Including by-product's cost share in Cost Analysis report (i.e. of a Done MO) - Updating corresponding BoM cost structure report 3. Also fixes an issue with Cost Analysis report not applying the currency rate when working in a multi-company/multi-currency situation. Task: 2440068 COM PR: odoo/odoo#74951 Upgrade PR: odoo/upgrade#2727
Resolved issues and error corrections
The payment follow-up workflow now keeps the existing reminder settings when someone chooses to be reminded later. It also prevents duplicate follow-up action names within the same company, making reminder setup clearer and less error-prone.
Original PR description
Pressing the "remind me later" button should : - neither change the follow up level - nor remove the auto/manual options - nor remove the possibility to change the next reminder date. Add a unicity constraint (per company) on the name of the payment follow up actions Task: 2308880
This fix restores access to worksheet templates for users who need them in field service tasks and quality checks. It ensures the system can safely retrieve the related model information without exposing unnecessary technical access, so teams can continue selecting and using worksheets as expected.
Original PR description
\* = industry_fsm_report and quality_check_worksheet Before this commmit, the access read to ir.model has been removed for users. So, the project user could not access to worksheet and cannot select a worksheet for fsm task. This commit adds `sudo` when it is necessary and adds new field to get the model in ir.model to use it in ir.rule defined in quality_control and industry_fsm modules. Related PR: odoo/enterprise#17633
Planning now records worked day counts with decimal precision instead of rounding each planning slot up to a full day. This prevents totals from being overstated when an employee has multiple slots on the same day, improving accuracy for planning reports and calculations.
Original PR description
`working_days_count` should be evaluated as a Float instead of an Integer, otherwise it could lead to incorrect result: suppose a user adds two slots on the same day and for the same employee. For now, `working_days_count` is an integer and its value is rounded up, so this field value for each slot will be 1 and therefore, even if the employee worked one day, the sum of `working_days_count` will be 2. From now on, `working_days_count` are stored as not-rounded floats (to remain as accurate as possible in the calculations). Note that, on client side, the displaying of this field will be automatically rounded: https://github.com/odoo/odoo/blob/e89b626f5411b7836030c6daa940b41f65747843/addons/web/static/src/legacy/js/fields/field_utils.js#L175-L174 Linked to OPW-2496638
A typo in the signing feature’s background request was corrected. This helps prevent a small technical error from interrupting parts of the document signing flow.
This change restores compatibility for report template rendering after a previous update changed the format returned by the rendering process. It helps prevent report-related failures in affected payroll and Studio workflows, keeping document generation reliable for users.
Original PR description
Partial revert of a6262db16ae89 (see #20189 which does similar fix) Community: https://github.com/odoo/odoo/pull/75377
Code cleanup and technical improvements
The Documents spreadsheet screens were migrated to Odoo's newer action framework, helping keep the interface maintainable and aligned with current platform standards. Existing spreadsheet links remain compatible while a clearer spreadsheet identifier is introduced to reduce confusion.
Original PR description
This commit converts the spreadsheet and template client actions
to new wowl actions.
Note: there are two "service-like" classes introduced in this commit.
They act as an interface between the actions and the server to hide
model specificities ("documents.document" vs "spreadsheet.template")
There are not actually registered as services since they are used only once.
Better naming ideas for those classes are welcome.
TODO (in the future)
- convert helpers to use the new orm service
- remove action inheritance (abstract spreadsheet action).
There are better ways to achieve the same thing without inheritance
which might not be straight forward to read and a bit fragile.
Task 2621549
Co-authored-by: fleodoo <fle@odoo.com>Miscellaneous changes
odoo treats 'x_studio_partner_id' field as many2one when calling _message_add_suggested_recipient. there are geting id from partner passed by this method. But we are not restrict there to create x_studio_partner_id field as many2one only. if there may different ttype of the field with same name, as this method is passsing that field's value to add in recipients, there is traceback in backend. Here is tracback: ... Traceback (most recent call last): File "/home/hpr/odoo/community/od
Original PR description
odoo treats 'x_studio_partner_id' field as many2one when calling _message_add_suggested_recipient. there are geting id from partner passed by this method. But we are not restrict there to create…
odoo treats 'x_studio_partner_id' field as many2one when calling
_message_add_suggested_recipient. there are geting id from partner
passed by this method. But we are not restrict there to create
x_studio_partner_id field as many2one only.
if there may different ttype of the field with same name, as
this method is passsing that field's value to add in recipients,
there is traceback in backend.
Here is tracback:
...
Traceback (most recent call last):
File "/home/hpr/odoo/community/odoo/addons/base/models/ir_http.py", line 237, in _dispatch
result = request.dispatch()
File "/home/hpr/odoo/community/odoo/http.py", line 684, in dispatch
result = self._call_function(**self.params)
File "/home/hpr/odoo/community/odoo/http.py", line 360, in _call_function
return checked_call(self.db, *args, **kwargs)
File "/home/hpr/odoo/community/odoo/service/model.py", line 94, in wrapper
return f(dbname, *args, **kwargs)
File "/home/hpr/odoo/community/odoo/http.py", line 348, in checked_call
result = self.endpoint(*a, **kw)
File "/home/hpr/odoo/community/odoo/http.py", line 913, in __call__
return self.method(*args, **kw)
File "/home/hpr/odoo/community/odoo/http.py", line 532, in response_wrap
response = f(*args, **kw)
File "/home/hpr/odoo/community/addons/mail/controllers/main.py", line 296, in message_get_suggested_recipients
return records._message_get_suggested_recipients()
File "/home/hpr/odoo/enterprise/web_studio/models/mail_thread.py", line 19, in _message_get_suggested_recipients
obj._message_add_suggested_recipient(result, partner=obj.x_studio_partner_id, reason=self._fields['x_studio_partner_id'].string)
File "/home/hpr/odoo/community/addons/mail/models/mail_thread.py", line 1498, in _message_add_suggested_recipient
if partner and partner in self.message_partner_ids: # recipient already in the followers -> skip
File "/home/hpr/odoo/community/odoo/models.py", line 5547, in __contains__
raise TypeError("Mixing apples and oranges: %s in %s" % (item, self))
Exception
...
Forward-Port-Of: odoo/enterprise#20187