edit_inline ... foreignkey(core=True) bug

[judgej@…]

Spent days fighting this, found lots of django-users and tickets somewhat associated. My solution found.

Example:
class Parent(models.Model):

name = models.CharField(maxlength=100
class Admin: pass

class Child(models.Model):

variable=models.CharField(maxlength=32)
value=models.IntegerField()
folks = models.ForeignKey(Parent, core=True, edit_line=models.Tabular)

Bug:
Django happy since you have a core=True in any child member.
DB tables get created fine.
Can create a Parent in the admin interface ... and stick in a couple children.
But ==> no children ever get saved.

Stick core=True in the other members, it still won't work.
You have to remove core=True in the ForeignKey() member.

[bangcok_dangerus (at) hotmail.com]

I've also encountered this problem.

As I see it, it doesn't make sense to have 'core=True' on the same field you've specified 'edit_inline=...' on. The value for this field is obviously automatically set to the id of the 'parent' related object. Specifying 'core=True' on the 'edit_inline=...' field makes the admin silenty throw away your form input and wrongly report that the parent object was successfully save/altered.

[amcnabb@…]

I'm having the same problem with ForeignKey fields. Unfortunately, I can't work around the problem by removing core=True from all edit_inline objects. The model in question has three ForeignKey fields, all of which have core=True and edit_inline=True. There aren't any other fields that I can make "core", so the workaround here doesn't work.

So, somehow the inlined object needs to ignore the "core" property for the field that refers to the enclosing object. Does that make sense?

P.S. I can't figure out why the system thinks that this comment is spam.

[Simon G. <dev@…>]

Can someone build a test case/example of this to help us debug it?

[erob@…]

Whats the error msg?
Here it says: TypeError: 'int' object is unsubscriptable.

Traceback (most recent call last):
File "/usr/local/users/erob/django/django/core/handlers/base.py" in get_response

77. response = callback(request, *callback_args, callback_kwargs)

File "/usr/local/users/erob/django/django/contrib/admin/views/decorators.py" in _checklogin

55. return view_func(request, *args, kwargs)

File "/usr/local/users/erob/django/django/views/decorators/cache.py" in _wrapped_view_func

39. response = view_func(request, *args, kwargs)

File "/usr/local/users/erob/django/django/contrib/admin/views/main.py" in add_stage

254. new_object = manipulator.save(new_data)

File "/usr/local/users/erob/django/django/db/models/manipulators.py" in save

172. if f.core and not isinstance(f, FileField) and f.get_manipulator_new_data(rel_new_data, rel=True) in (None, ):

File "/usr/local/users/erob/django/django/db/models/fields/init.py" in get_manipulator_new_data

288. return new_data.get(self.name, [self.get_default()])[0]

TypeError at /sysadmin/polls/poll/add/
'int' object is unsubscriptable

theres no core=True in the foreignkey... however its definitely not
the expected result. is that the same bug we're talking?

many thanks

[erob@…]

some fun with rel :)

[erob@…]

Please tell me if that patch works for you.
It is working for me for using core=True on child members,
in a very simple Poll/Choice app:

Choice model:

class Choice(models.Model):
      poll   = models.ForeignKey(Poll, edit_inline=models.TABULAR, \
        max_num_in_admin=3, num_extra_on_change=0)
      choice = models.CharField(maxlength=200, core=True)
      votes  = models.IntegerField(core=True, default=0)
      def __str__(self):
          return self.choice
      class Admin:
            pass

As a work-around, apply the patch and use max_num_in_admin and num_extra_on_change
to see if it makes any differences.. It seems to break things without theses, but
with the following changes, it doesnt show any error while trying to add new polls
in the admin. As a side-note, I havent found good docs for the rel attribute,
what is this for anyway ??

[Gary Wilson <gary.wilson@…>]

FYI, setting a ticket resolution as worksforme is not intended for specifying whether or not a patch works, but rather for indicating that the problem is not reproducible and is not a bug.

[erob@…]

To Gary:

FYI, seriously, that is odd. But I dont want to impose to you a way
to think over another, so if you feel "worksforme" means whatever else,
then I'm happy with that.

On another side, it would have been great or perhaps
more informative to know if the patch works for you,
rather than 1) imposing your way of thinking to the others, 2)
not giving any helpful inputs related to this issue.

In the former case I would be happy to hear from you
again.

Thanks,
Etienne

[James Bennett]

I don't think there's any "imposing" going on here, just an explanation of what we use the "worksforme" status for -- when we mark a bug "worksforme" it means "I tried to reproduce the bug and couldn't, please check your setup and see if it still happens". When there's a patch which fixes the bug, we leave it open until the patch gets committed into Django, so that we can make it work for everybody :)

[erob@…]

... What does ubernostrum means anyway? ;-)

[Simon G. <dev@…>]

Replying to erob@cpan.org:

... What does ubernostrum means anyway? ;-)

An extremely powerful medicine that cures all.

Reading the comments here, I think we need to clarify the docs regarding triage resolution states ^{I've created #3658 to do this.}

[anonymous]

Replying to Gary Wilson <gary.wilson@gmail.com>:

FYI, setting a ticket resolution as worksforme is not intended for specifying whether or not a patch works, but rather for indicating that the problem is not reproducible and is not a bug.

OK, I'll pay more attention to the triage states semantics next time.

Please accept my apologies.

Regards,
Etienne

[Brian Rosner]

This is no longer a problem with newforms-admin. core=True usage is completely gone. Tagging with nfa-fixed to be closed when newforms-admin is merged.

[Michael Newman]

I do believe the recent merge has fixed this issue.