"Editable = False" + "Edit Inline" in new forms admin

Ok, what needs to be fixed here is the BaseModelFormSet always makes the primary key as a hidden field. That is wrong and should understand the difference between an automatically created primary key and a custom override. When it is overidden such as your case above it should always allow the field to edited by the user. It would be wrong to treat them the same since Django cannot provide the value implicitly. Therefore the exception you see in the editable=False case is correct. You would have to provide it yourself.

Actually let me re-think this. I am missing something here.

basically if 'editable = True' (or not set)

the 'inline edit' _does_ hide the field because it is a primary Key, so that is correct .. what is werid is that is shows the 'label' for it still

i.e. in the above examples

product handling id | <input hidden>
handle option | <select menu>

it really should be just

<input hidden>
handle option | <select menu>

but if editable = false, it forgets to add the input hidden so the form skeleton is just

handle_option | <select menu>

thus the 'save aux elements' in the form.cleaned_data is lacking the PK to save it

I disagree. When editable=True on a custom primary key and non-AutoField the field should *show* on the form. There is no way of providing that value otherwise unless of course you provide it at the code level. The correct fix and I stand by what I said earlier is that custom primary keys should always show on the form.

Sure, Editable = True can certainly show the input box .. not much to disagree about there, that's just one part of the bug.

The other part is the 'editable = false',

In the inline Model, being a Primary Key, should always slap a hidden field regardless of the edit-ability of it

the above patch still does not address that little issue.

It's almost as if any place there is an " if not editable " it needs to be conditioned with " if not editable and not primary_key "

here is a small little patch .. however, it still shows the 'hidden' row in the inline stacked presentation .. but at least the PK is in the form and so it can update/save the object

Force the display of editable=false, pk=true for inline models (the field ends up being hidden)

I still think we are not coming to the right agreement here. Let me outline each case as I see it:

• If the primary key was automatically generated it is always hidden.
• If the primary key was defined by hand *and* is a of type AutoField (aka self.model._meta.has_auto_field) it is always hidden regardless of the editable value.
• If the primary key was defined by hand, is of some other type, and editable=True (or not given) it is always shown.
• If the primary key was defined by hand, is of some other type, and editable=False then it is *not* shown, but if not given a value before saving the database will complain (correct behavior).

There doesn't need to be any changes to newforms outside of a formset because the bug is formset specific. newforms handles everything correctly. I hope I am not repeating what you are saying, but your patch indicates fixing the wrong thing and doesn't even appear correct.

ya, the patch is not 'right' and is more to demonstrate what i think 'should' happen (the PK shows up, but is not editable).

but the issue involves your last statement

• If the primary key was defined by hand, is of some other type, and editable=False then it is *not* shown, but if not given a value before saving the database will complain (correct behavior).

When one edits Inline, the PK still needs to be there for the saving to work. Its not the DB complaining, its the Form Validator complaining it cannot find the PK as it wants to update things.

#this works (does NOT show the editbox)
	product_handling_id = models.AutoField(primary_key=True)
# this works (but shows the edit box)
	product_handling_id = models.PositiveIntegerField(primary_key=True)
#this fails
	product_handling_id = models.AutoField(primary_key=True, editable = False)
#this fails
	product_handling_id = models.PositiveIntegerField(primary_key=True, editable = False)

If you try the admin from the above example the PK field never makes it into the form, thus makeing it editable when it should not be (PositiveIntegerField? vs AutoField? is really a Database Optimization, as the default AutoField? translates into an IntField?).

Soooo. It seems the Field definitions should allow for a keyword that says "I Am The AutoField?", which given the proximity to v1.0 probably won't happen.

PositiveIntegerField(primary_key = True, auto_field = True)

Ok, in order to effect the my auto_field = True Field option, here is a bigger patch, that does just that

used exactly like

my_col = models.PositiveIntegerField(primary_key = True, auto_field = True)

And this will be treated like any other "AutoField?" field, except now we get to specify a custom db_type,

I Am aware i can probably just subclass AutoField?, so if y'all think this is too silly, just mark the thing as fixed using the little patch brosner posted

(bad diff file)

Ok, so we have finally uncovered that we were dealing with two different issues that are closely related. The patch I posted is indeed fixing part of the problem and I will commit. Either open a new ticket or see if it has been reported before, it likely has about a custom AutoField. It would likely take the route of just subclassing AutoField there.

The original problem also exists in the following situation

class Fruit(models.Model)
    name = models.Charfield("Name", max_length=50)

class Apple(models.Model)
    organization = models.OneToOneField('Fruit', primary_key=True
    color = models.Charfield("Name", max_length=50)

class AppleInline:
    model = Apple

class FruitAdmin
    inlines = [AppleInline]

In this case, when editing an existing product, the hidden field created doesn't have a value:

<input type="hidden" id="some_value" class="some_value" /> value="" is missing

Ok, the original problem actually (I know realize) is a duplicate of #7888. Marking as so. However, this ticket also discovered a different bug that I will commit now.

Actually thinking about it. This really isn't a duplicate, but rather a primary key should not be marked editable=False since that will caused the above error. The built-in AutoField returns None in its formfield method which causes it to not display but is still accessible in the cleaned_data dict. To accomplish this now just subclass the field type and do the same. Otherwise open a new ticket regarding custom primary keys since this describes it as being a formset issue, which it really isn't.

(In [8179]) Ensure that custom primary keys are always shown on a formset. Refs #7938. Thanks magneto for discovering this problem.