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 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.
Denis Ledoux