Sorry for my lack of prompt response. Mostly, we want to hide the underlying user mechanism from the people that are going to use this admin interface. We want email addresses to be the unique identifiers in the system, and for records with the same email address to be automagically associated with one another, without the admins having to have any notion of foreign keys, etc.
The particular use case is that we want to track meeting attendees, and each attendee at each meeting gets a record. Meeting organizers will do data entry (either by hand or via API) to add their attendees to the system. Attendees that have already attended previous meetings should be able to log into the new meeting with their existing credentials, use existing preferences, etc., whereas new attendees should be assigned a random password, but whatever person or automated process is doing data entry shouldn't have to care, nor should they be able to muck with the process by associating people with different addresses together. Andrew On Oct 11, 2:06 pm, Brian McKeever <kee...@gmail.com> wrote: > Is there a reason why you're storing an email address instead of just > selecting the user or creating a new one? > > On Oct 10, 12:41 am, Andrew Pendleton <abp...@gmail.com> wrote: > > > I'm trying to figure out the best way to add an email address form > > field to the edit page for a model in the Django admin, and, upon > > save, automatically set a hidden foreign key to associate said model > > instance to the Django user with this email address, or, > > alternatively, create a new user with said email address if one > > doesn't already exist. > > > Things I've thought of: > > * Add an actual database field for the email address, in addition to > > the ForeignKey that's already there, and add some glue in the save() > > method to set the second based on the first. This seems to be the > > easiest to implement, but I don't like the unnecessary duplication of > > data, and I'd also like the foreign key relationship to be maintained > > once it's set, even if the email address of the User changes, and it > > seems like there's risk of breakage in that event, with this approach. > > * Use a custom form for the model in the admin that tacks on an extra > > field, and, again, do some voodoo in save. > > * Make the foreign key field visible, but write a custom widget for it > > that looks like a regular text box, but looks to Django like a foreign > > key field. > > > Would any of these work well? If so, which would be best? Am I > > missing anything? With which might it be easiest to reuse the same > > logic in a piston-powered API that exhibits the same behavior? > > > Relatedly, in my application, it will be possible, but rare (and > > likely unintentional) for more than one instance of this model to be > > associated with the same User instance. In the event that I get this > > kind of likely-incorrect submission, is there a way to force a > > confirmation screen with a warning on it for a save in the admin, but > > let the user proceed if they really want to? > > > Thanks, > > Andrew > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
