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
I added a few extra fields to customise the Invite model and passed the CustomInvite model name to settings.
InvitationAdminChangeForm shows all fields, therefore new extra fields were both shown and saved.
InvitationAdminAddForm wasn't showing new fields, because the original code is very explicit as to which fields it shows. It would be nice if it were showing extra fields. As a solution, I created CustomInvitationAdminAddForm and passed the name of the form to settings. Unfortunately, I originally decided to inherit from InvitationAdminAddForm which caused a different problem:
The second problem I was facing is that InvitationAdminAddForm didn't save data, even when I added these fields to the form and passed a new form name to settings. New fields were now shown in the form, but data wasn't saved.
It seems like the issue may be caused by this approach in the save() method in the original form in invitations.forms.InvitationAdminAddForm
It seems that instead of creating an Invitation from cleaned_data, it is created from params (email and optional inviter) therefore completely ignoring the new field added to the custom model. I solved this problem by customising save() method and making sure the instance is created with all cleaned_data.
Fixing the problem in save() would allow developers to use invitations in Django admin without customising the form because new fields would be automatically captured.
To summarise: In invitations.forms.InvitationAdminAddForm in save() instance could be created from all cleaned_data instead of **params (inviter and email only). This would be helpful because developers who customise the Invite model in their project, don't have to customise the save() method in this form. They would only need to add fields to the form.
Optionally maybe we could consider adding fields = "__all__" this way no customisation of InvitationAdminAddForm would be required. The developer could customise Invite and have all Django admin functionality working.
The text was updated successfully, but these errors were encountered:
I added a few extra fields to customise the Invite model and passed the CustomInvite model name to settings.
InvitationAdminChangeForm shows all fields, therefore new extra fields were both shown and saved.
InvitationAdminAddForm wasn't showing new fields, because the original code is very explicit as to which fields it shows. It would be nice if it were showing extra fields. As a solution, I created CustomInvitationAdminAddForm and passed the name of the form to settings. Unfortunately, I originally decided to inherit from InvitationAdminAddForm which caused a different problem:
The second problem I was facing is that InvitationAdminAddForm didn't save data, even when I added these fields to the form and passed a new form name to settings. New fields were now shown in the form, but data wasn't saved.
It seems like the issue may be caused by this approach in the save() method in the original form in
invitations.forms.InvitationAdminAddForm
It seems that instead of creating an Invitation from cleaned_data, it is created from params (email and optional inviter) therefore completely ignoring the new field added to the custom model. I solved this problem by customising save() method and making sure the instance is created with all cleaned_data.
Fixing the problem in save() would allow developers to use invitations in Django admin without customising the form because new fields would be automatically captured.
To summarise: In
invitations.forms.InvitationAdminAddForm
insave()
instance could be created from allcleaned_data
instead of**params
(inviter and email only). This would be helpful because developers who customise the Invite model in their project, don't have to customise the save() method in this form. They would only need to add fields to the form.Optionally maybe we could consider adding
fields = "__all__"
this way no customisation ofInvitationAdminAddForm
would be required. The developer could customise Invite and have all Django admin functionality working.The text was updated successfully, but these errors were encountered: