Clone must use addSkel, not an editSkel

[tsteinruecken]

When cloning an entry, the form must use the structure from an addSkel, not an editSkel. Currently, we simply use the editForm and reset its Key to None (so data will be pushed to /module/add instead). But addSkel and editSkel might have different structures (like readOnly fields that can only be set once during add). These would currently be still readOnly and clone not possible on such modules.

[phorward]

There had been several modifications on the widgets/edit.py file which already should solve this issue since v2.3. Please verify it with your case and report whether it is working or working.

[tsteinruecken]

I can confirm that this bug is still present in

ViUR Visual Interface v2.3.0 Rev fd3715ded630ea93b3ca4d915abb0b4e851103ca Built Di 27. Nov 15:14:16 CET 2018

[phorward]

OK thanks, then I'll gonna test it with develop.

[phorward]

Hello!

After a short examination of this problem, I will not fix this issue for ViUR 2.x because of the following reasons which have their origin in ViURs current design: To create a clone of an existing dataset using the add-function, I first have to call edit with the existing key to obtain the data of the source entity. I cannot call the add-function with an exiting key! Then, I would need to send this data, again, to the appropriate add function of the module to verify them with the according addSkel. But to send data to the add function, I first have to render the bones from the editSkel, unserialize the values to the bones, immediately serializeForPost the values again from the bones to construct a POST request for the add, destruct the bones, call the add-function, rebuild the bones again according to the addSkel with the values from the former entity and unserialize them again. You have to admit, that this will bloat the entire solution for this problem and will become extremely slow.

My proposal for a smart solution would be to provide a clone() function for all modules which read an entity from a key but returns the according addSkel. Maybe this could be combined with the hierarchy cloning features from Tree and Hierarchy.

For now I would tag this issue for v3.0, everything else makes no sense.