Thursday, May 4, 2023
3 changes · master
Resolved issues and error corrections
Fixed an issue that prevented users from quickly creating tasks from the My Tasks kanban view. This avoids an error message during task entry and helps users add personal tasks without interruption.
Original PR description
The refactor of the kanban quick create implemented in https://github.com/odoo/odoo/pull/117449 introduced a traceback when creating a task from the My Tasks kanban view due to the presence of…
The refactor of the kanban quick create implemented in https://github.com/odoo/odoo/pull/117449 introduced a traceback when creating a task from the My Tasks kanban view due to the presence of 'default_personal_stage_type_ids' key in the context. This commit fix that by removing this key from the context in the customization of the kanban view for project.task model. It also add a js tour test to ensure that personal tasks can be created from the quick create form in the My Tasks kanban view. Steps ===== - Install module project - Go to the view "Tasks -> My Tasks" - In the main Kanban View click on "New" - Enter a Task title and clicl on "ADD" Issue ===== A traceback appears indicating that the value of the field user_id is missing for the model project.task.stage.personal and the task is not created. Cause ===== In kanban and list views, when the records a grouped by a given field, a key is added in the context when creating a record from one of the resulting categories. This key is of the form: `default_fieldGroupedBy: current_category_value` In the case of the view My Tasks, the records are grouped by their fields personal_stage_type_ids (M2M). Therefore, the key default_personal_stage_type_ids will results in a write in that M2M table when creating the record. But the way personal stages are managed in project is as confusing as it is mindblowing and the M2M table storing the relation between task and personal stages is also the table that store records from the model project.task.stage.personal. And this model also as a field user_id that is required. Therefore at creation of the project.task record with that key, the orm will miss a user_id for the newly created project.task.stage.personal. Fix === The correct way to add/modify a record project.task by setting its personal stage is actually to use the already existing methods of project.task, i.e. _inverse_personal_stage_type_id. Therfore, instead of modifying directly the M2M relation, update the computed M2O field and let the inverse method to the job of personal stage assignment. To do that, the value contained in the context for the M2M relation is copied in the write value of the M2O (personal_stage_type_id) and the key in the context corresponding to the M2M relation is deleted. task-3281005
The messaging menu now shows channel unread and action-needed indicators in the same way as the Discuss sidebar. This reduces duplicate channel entries, makes important messages easier to spot, and prioritizes items that need attention.
Original PR description
Before this commit, unread and needaction shown in messaging menu was inconsistent with discuss sidebar. In discuss sidebar, unread channel are bold, and needaction are shown with badge + counter. In messaging menu, previews could be either unread or needaction previews, and channels had 2 previews, one for unread, and the other for needaction. This commit make the messaging menu preview of channels more consistent with discuss sidebar: - channels have a single preview for unread and needaction - unread messages make title bold, unread counter is no longer shown - the counter displays needaction on this channel instead. This commit also improves ordering of messaging menu items, so that: - needactions have precedence over non-needactions - unread channels have precedence over read channels Task-3293723 <img width="1274" alt="Screenshot 2023-04-28 at 17 48 47" src="https://user-images.githubusercontent.com/6569390/235194397-5d6637f1-5da1-4908-8d6f-22da135b3d35.png">
Fixed an issue where embedded external records or links added to Knowledge articles could be lost when users clicked into them before the article was saved. The article now correctly detects these edits and saves them, improving reliability for Knowledge and Helpdesk content updates.
Original PR description
This commit fixes a bug where external insertion inside an article would not be saved if you clicked on a record inside the view or opened the link. This is caused because the article was not flagged as dirty when opening either a record or a link which does not trigger a save by the field html. Now when we are finished inserting we are asking the record to check for changes which will flag the field as dirty and will trigger the save mechanism on opening an external record/link. We also adapted one of the tour in website_helpdesk_knowledge that test cross module features or knowledge to take this behavior into account. task-3292309