* status: reopened => new
* owner: nobody => dArignac
* ui_ux: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/13696#comment:10>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/13696#comment:11>
* status: assigned => closed
* has_patch: 0 => 1
* resolution: => fixed
--
Ticket URL: <https://code.djangoproject.com/ticket/13696#comment:12>
* status: closed => reopened
* resolution: fixed =>
Comment:
Replying to [comment:12 dArignac]:
> Status changed from assigned to closed
Thanks for the patch! But there is no need to close the ticket as
''fixed'', the ''has patch'' one is the way to mark it has a fix a fix
ready for review.
''Fixed'' is used when/if the issue is actually fixed either by applying
it (or another fix) to the code (by a core committer) . Otherwise it will
be completely under the radar for people looking for unsolved tickets or
patches to review and commit, causing effectively the exact contrary
effect to the one you intended when you worked in the issue in the first
time.
See https://docs.djangoproject.com/en/dev/internals/contributing/triaging-
tickets/#closing-tickets
--
Ticket URL: <https://code.djangoproject.com/ticket/13696#comment:13>
Comment (by dArignac):
Oh ok, sorry, so I got it wrong. Will not happen next time!
Replying to [comment:13 ramiro]:
> Replying to [comment:12 dArignac]:
> > Status changed from assigned to closed
>
> Thanks for the patch! But there is no need to close the ticket as
''fixed'', the ''has patch'' one is the way to mark it has a fix a fix
ready for review.
>
> ''Fixed'' is used when/if the issue is actually fixed either by applying
it (or another fix) to the code (by a core committer) . Otherwise it will
be completely under the radar for people looking for unsolved tickets or
patches to review and commit, causing effectively the exact contrary
effect to the one you intended when you worked in the issue in the first
place.
>
> See https://docs.djangoproject.com/en/dev/internals/contributing
/triaging-tickets/#closing-tickets
--
Ticket URL: <https://code.djangoproject.com/ticket/13696#comment:14>
* cc: issac.kelly@… (added)
* stage: Accepted => Ready for checkin
Comment:
Tested against 1.4-pre-alpha and still fixes this issue.
--
Ticket URL: <https://code.djangoproject.com/ticket/13696#comment:15>
* stage: Ready for checkin => Accepted
Comment:
The note in this comment:
https://code.djangoproject.com/browser/django/trunk/django/forms/models.py?rev=17373#L637
seems to indicate that !AutoField's ''editable'' value isn't False so I
don't think this patch is ready for commit. The condition in the ''if''
test would need to be a bit more complex than the two proposed so far:
Checking for the field being a PK field (as implemented in the patch) or
checking of it being a PK and not editable.
--
Ticket URL: <https://code.djangoproject.com/ticket/13696#comment:16>
Comment (by dArignac):
I don't get where exactly the problem now is. If I include an AutoField
setting its property "editable" to True, it still cannot be edited within
the AdminSite, there is also no problem saving this. For all custom Fields
being primary keys (primary_key=True) the current fix does work. Please
explain, thanks!
--
Ticket URL: <https://code.djangoproject.com/ticket/13696#comment:17>
Comment (by brianglass):
I am affected by a very similar problem (though technically unrelated) in
the same template. When I have a model that has a field that is not named
id, the "View on site" link in the inline editing section is missing the
pk in the url. So the link ends up going to nowhere. The relevant code is:
{{{
{% if inline_admin_form.show_url %}<a href="../../../r/{{
inline_admin_form.original_content_type_id }}/{{
inline_admin_form.original.id }}/">{% trans "View on site" %}</a>{% endif
%}
}}}
Instead of {{ inline_admin_form.original.id }}, I think it should be {{
inline_admin_form.original.pk }}.
--
Ticket URL: <https://code.djangoproject.com/ticket/13696#comment:18>
Comment (by evan.reiser@…):
Brianglass: Yes. I agree. It's such an obvious and easy fix, its too bad
that there is so much bureaucracy around changing it.
The underlying problem is that the code is assuming you always have
primary keys named "id" that are auto incrementing, which obviously isn't
the case.
--
Ticket URL: <https://code.djangoproject.com/ticket/13696#comment:19>
Comment (by anonymous):
We've been bitten by this as well. This bug has been replicated in Django
grappelli. So for anyone that bumps into this bug you can override
admin/edit_inline/tabular.html and/or admin/edit_inline/stacked.html
similarly to the patch that's been posted here.
Also note that django_extensions' UUIDField contains a hack to work around
this bug. It pretends to be an auto field, which doesn't work well, as
pointed out by wolever above. I'm trying to get that hack removed from
django-extensions: https://github.com/django-extensions/django-
extensions/pull/332
--
Ticket URL: <https://code.djangoproject.com/ticket/13696#comment:21>
Comment (by kmtracey):
Pull request with slightly altered fix:
https://github.com/django/django/pull/1381
The proposed fix duplicated the pk field on the inlines if there was a
non-auto EDITABLE pk field already rendered. The pull request tests for
that (previous fix would fail that test) in addition to testing for the
non-auto non-editable pk.
--
Ticket URL: <https://code.djangoproject.com/ticket/13696#comment:22>
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"3aad955ea8db1592fad0012155eaa25b72e50dc5"]:
{{{
#!CommitTicketReference repository=""
revision="3aad955ea8db1592fad0012155eaa25b72e50dc5"
Fixed #13696 -- ensured inline pk field is rendered
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/13696#comment:23>
Comment (by Karen Tracey <kmtracey@…>):
In [changeset:"706e542eb5db0d14277f34566d351b875e645bac"]:
{{{
#!CommitTicketReference repository=""
revision="706e542eb5db0d14277f34566d351b875e645bac"
[1.6.x] Fixed #13696 -- ensured inline pk field is rendered
Backport of 3aad955ea8db1592fad0012155eaa25b72e50dc5 from master.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/13696#comment:24>