You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a question is duplicated, the intention is to re-ask it, possibly making some changes beforehand.
Django's built-in 'save-as' doesn't work, because it will copy the asked and answered fields, whose values prevent further editing of the model.
We've been using modelclone, which provides a duplicate button in the admin and an intermediate view, which is kind of a patched-up version of the django change view. However, it's not brilliantly architected, or maintained properly, and a problematic issue is that the workaround for RealGeeks/django-modelclone#41 botches the context to be that of 'add' always, meaning you don't get access to the original obj when overriding render_change_form (i.e. the workaround creates other bugs).
This means that currently, when a question is duplicated:
any fields on an inherited model are duplicated and pre-filled, which is not the desired behaviour
What is the expected behavior?
The render_change_form functionality should work as expected, as opposed to behave like it's adding all the time.
Only the desired fields should be duplicated
Proposed solution
We need to move away from modelclone. Whilst there are other better maintained libraries out there like https://github.com/tj-django/django-clone, it's probably better to provide this functionality out-of-the-box from django-twined, with some kind of overridable behaviour to allow for question inheritance.
The text was updated successfully, but these errors were encountered:
Bug report
What is the current behavior?
When a question is duplicated, the intention is to re-ask it, possibly making some changes beforehand.
Django's built-in 'save-as' doesn't work, because it will copy the
asked
andanswered
fields, whose values prevent further editing of the model.We've been using
modelclone
, which provides aduplicate
button in the admin and an intermediate view, which is kind of a patched-up version of the django change view. However, it's not brilliantly architected, or maintained properly, and a problematic issue is that the workaround for RealGeeks/django-modelclone#41 botches the context to be that of 'add' always, meaning you don't get access to the originalobj
when overridingrender_change_form
(i.e. the workaround creates other bugs).This means that currently, when a question is duplicated:
What is the expected behavior?
render_change_form
functionality should work as expected, as opposed to behave like it's adding all the time.Proposed solution
We need to move away from modelclone. Whilst there are other better maintained libraries out there like https://github.com/tj-django/django-clone, it's probably better to provide this functionality out-of-the-box from
django-twined
, with some kind of overridable behaviour to allow for question inheritance.The text was updated successfully, but these errors were encountered: