id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
13199	Better documentation of things to avoid in the comments framework	Yeago	nobody	"I got myself into a situation with a project and some comments models. Perhaps with some discussion we can uncover genuine code-bugs, but my knowledge about this is limited and so I'm just calling for a documentation update. A major reason I'm asking for some notice of these things to appear somewhere is that all of the below seems to work perfectly fine in the dev server. On deployment, its a confusing catastrophy that, at best, gives you a vague ImproperlyConfigured(""The COMMENTS_APP setting refers to a non-existing package.""), which is of course no help at all.

Three things:

1) Its not obvious to me why, but importing a custom comment model as 'Comment' seems, somehow, to get back upstream to django.contrib.comments and wreck things. If this is due to the nature of that particular frameworks' immaculate ability to be extensive and provide conveniences all around, so be it. I'd just like a notice next time before I attempt to save code by doing Comment = comments.get_model() and expect everything to be honkey dorey.

2) A custom comments app should not also be called 'comments'. Probably a very obvious one but the problems it creates are inconsistent between dev and live and not obvious.

3) Models hoping to foreignkey to whatever comments model the app provides should not be passed the callable. I realize passing callables into a ForeignKey probably seems strange in and of itself, however, once again it creates inconsistent problems between dev and live which never connect back to the FK in any obvious way."		closed	contrib.comments	1.2-beta		invalid			Unreviewed	0	0	0	0	0	0