Repository navigation
[18.0][IMP] project_task_description_template: project templates and portal support - #1848
ThiagoMForgeFlow wants to merge 3 commits into
Conversation
OCA-git-bot
added
series:18.0
mod:project_task_description_template
|
CI depends on #1849 : project_key blocks task creation for portal users |
|
Hi @pedrobaeza @rousseldenis @alan196, could you please review this PR? It extends the module with per-project templates and portal support (see the description for the design decisions, especially the change to a stored template field). |
|
You should check CI first. |
As mentioned above, the CI is failing due to an error in the project_key module. The PR that fixes this issue is #1849 |
The template field was not stored since the module was created, so the template used on a task was lost after saving it.
b923717 to
cadb83f
Compare
Templates can be linked to projects, so each project only proposes its own templates and the ones without projects.
cadb83f to
ce927b0
Compare
|
Hi @pedrobaeza the CI passes now |
|
This PR has the |
| <field name="description" invisible="1" /> | ||
| <field | ||
| name="description_template_id" | ||
| invisible="not portal_description_template_required" |
There was a problem hiding this comment.
On projects with templates that don't require one, portal users can only pick a template from the full form. Showing the field whenever the project has templates would be more consistent; it would need a small computed boolean.
There was a problem hiding this comment.
Thanks for the feedback! The change has been applied. The system now checks that the project has templates configured for the portal.
Portal users can select the templates of their projects in the project sharing views, and a project can require them to select one on every new task.
ce927b0 to
fec6690
Compare
Context
We use this module to give customers a predefined structure when they report tasks from the portal. To make that possible, templates need to be configurable per project, usable from the project sharing views, and enforceable for portal users.
Changes
The PR is split in three commits that can be reviewed independently:
1. Store the template on tasks
description_template_idwas declared withstore=Falsesince the module was created, so the selected template was lost after saving the task and the field always appeared empty when reopening it. There is no documented reason for this in the history of the module (the 14.0 version of a module with the same purpose, #1192, stored it).Storing it keeps track of the template used to create each task and is required to validate it server side (see commit 3). The onchange behaviour is unchanged: selecting a template still appends its content to the description.
2. Restrict templates by project
project_idsfield on templates, editable from both sides (template form and a new "Task Description Templates" block in the project settings).3. Portal support
project.milestone). Templates without projects are not visible to portal users.create). Sub-tasks are not affected.Functional overview
1. Configuration
Templates can be linked to projects from the template or from the new "Task Description Templates" block in the project settings. On portal projects, the "Require Description Template on Portal Tasks" option forces portal users to select a template when they create a task.
Screenshots
2. Internal users
On a task, internal users can select the templates of the task project and the templates without projects (global templates).
3. Portal users
Portal users can only see and use the templates of the projects they collaborate on. Global templates are not available to them.
Screenshot
When the project requires a template, the task cannot be created without one, both from the kanban quick create and from the form:
Screenshot
Selecting a template fills the task description with its content:
Screenshot
4. Template stored on the task
The selected template is now kept on the task after saving it:
Screenshot