Due to the side effect on related fields that are not readonly, the value is saved
in project although not changed. Putting it readonly avoids the problem.
Fixes#26156Closes#26171
The duplication of a task crashes at the following:
`content = myPad.getHtml(path).get('html', '')`
The copy mechanism is quite cumbersome:
- In `copy` method, generate an URL of a pad which doesn't exist since
`object_id` is still undefined.
- The `create` method somehow attempts to fill in the previously created
pad thanks to `_set_pad_value`.
The logic is made simpler. The pad URL field is set as `copy=False`,
therefore the create mechanism will take care of handling the pad
creation and its synchronization.
opw-1818757
This revision is similar to
6e8faf40bd
but for the opposite case:
When the task is using the pad,
somehow the regular `description` pad
was written as well on save, making both field
being saved together,
and when description is saved
its content is written on the pad.
Therefore, whatever you written in the pad,
the pad was overriden with the current content of
the task regular description field
opw-787773
The regional variations are not published on Transifex and hsould be translated
manually.
The translations are mainly from previous versions or contains buggy fuzzy
translations (not matching the real source string).
Clean based on the .pot and delete the empty files
Fixes#21733
Purpose
=======
Currently if a project doesn't use pads, the created and duplicated tasks will initialize/copy them. That could be a real issue when migrating customers if we create a task for all the existing issues, since the models have been merged.
Specification
=============
Avoid this falsy behavior. We're forced to crappy fix with a context key as the project.task model 'inherit' from pad.common.
The pad_project addon has a simple mission: allow the user to choose if
he wants to use pads in all tasks from a given project.
This is a noble goal, and the code actually works for projects which
have a 'use_pad' field set to true. However, when a project has
'use_pad' set to false, we have a critical issue, due to the way the pad
widget works.
The pad widget is kind of strange, because it is set on a field which
contains the url for a pad, and it should write itself (the same value),
whenever someone writes on the pad, so the server knows it has to fetch
the result and write it on the 'real' field. This means that the pad
widget has to write its value each time the user modifies the pad
content and press save. However, fun fact, we have no way of knowing
when something was changed inside the pad iframe, so we actually save
the value each time the form view is saved.
So, we have a problem now: the description field AND the description_pad
field are always saved, and they interfere with each other.
In this commit, we put the description_pad in readonly mode when it is
invisible, so we do not save its value at all for each edit/save cycle
(and prevent interference). It actually prevent calling the
generate_pad_url method, but a pad is still created by the server code
each time a task is created.