issue 6
(unused "username" param for psn.views.settings_social_networ...) Status changed by leah.culver
-
Status: Fixed
Status: Fixed
Older
Nov 18, 2008
issue 6
(unused "username" param for psn.views.settings_social_networ...) commented on by christyberghausen
- er.. how do I close this issue..
er.. how do I close this issue..
Nov 18, 2008
issue 6
(unused "username" param for psn.views.settings_social_networ...) commented on by christyberghausen
- I'm not using the views for shelfworthy either, but I can easily remove the unused username param ;)
I'm not using the views for shelfworthy either, but I can easily remove the unused username param ;)
Nov 18, 2008
r38
(removing unused 'username' param in psn.views.settings_socia...) committed by drackett
- removing unused 'username' param in psn.views.settings_social_networks
removing unused 'username' param in psn.views.settings_social_networks
Nov 18, 2008
issue 6
(unused "username" param for psn.views.settings_social_networ...) commented on by leah.culver
- For pownce we're not using the views. I've pinged drackett about this so it should be
resolved shortly.
For pownce we're not using the views. I've pinged drackett about this so it should be
resolved shortly.
Nov 14, 2008
issue 5
(Script error) commented on by ericdrex
- see #6, my bad creating a duplicate ticket
see #6, my bad creating a duplicate ticket
Nov 14, 2008
issue 6
(unused "username" param for psn.views.settings_social_networ...) commented on by ericdrex
- ahem, needs a patch?
ahem, needs a patch?
Oct 13, 2008
issue 6
(unused "username" param for psn.views.settings_social_networ...) reported by ericdrex
- psn.views.settings_social_networks takes a 2nd "username" param which it
doesn't use. This breaks the instructions for setting up the default views.
Removing the username param from the function def fixes. Maybe the artifact
of some unfinished refactoring?
Great app btw, closes several tickets in one swoop for me :)
psn.views.settings_social_networks takes a 2nd "username" param which it
doesn't use. This breaks the instructions for setting up the default views.
Removing the username param from the function def fixes. Maybe the artifact
of some unfinished refactoring?
Great app btw, closes several tickets in one swoop for me :)
Oct 01, 2008
issue 5
(Script error) reported by michael.larue
- What steps will reproduce the problem?
1. Access settings/social_networks/ url
2.
3.
What is the expected output? What do you see instead?
expected 2 parameters (1 found) error.
What version of the product are you using? On what operating system?
Latest SVN
Please provide any additional information below.
Removing username from psn.views.settings_social_networks or giving an
empty default value will bypass.
What steps will reproduce the problem?
1. Access settings/social_networks/ url
2.
3.
What is the expected output? What do you see instead?
expected 2 parameters (1 found) error.
What version of the product are you using? On what operating system?
Latest SVN
Please provide any additional information below.
Removing username from psn.views.settings_social_networks or giving an
empty default value will bypass.
Sep 10, 2008
issue 4
(Don't register admin files in model definition files) Status changed by leah.culver
- I've moved the admin classes into admin.py. Thanks Malcolm!
Status: Fixed
I've moved the admin classes into admin.py. Thanks Malcolm!
Status: Fixed
Sep 10, 2008
r37
(fix for #4. Moved admin registration to admin.py. Thanks mal...) committed by leah.culver
- fix for #4. Moved admin registration to admin.py. Thanks malcolm.
fix for #4. Moved admin registration to admin.py. Thanks malcolm.
Sep 10, 2008
issue 4
(Don't register admin files in model definition files) reported by malc...@pointy-stick.com
- In r35 the various changes were made to port psn to the new Django admin
code. However, it now registers the admin classes in the models.py file.
This is bad practice and actually can cause difficult-to-diagnose crashes
when using the admin code. Basically, models files can be imported more
than once and duplicate admin registration goes badly, including leading to
circular import problems at times. You really don't want to have to handle
those bug reports (it will look like a django-psn problem because when
somebody removes django-psn, the problem will go away).
The recommended approach is to put admin classes and registration into an
admin.py file. This keeps it out of models.py and also means that anybody
using django-psn and admin.autodiscover() will have those admin classes
automatically registered (autodiscover() knows to look for a module called
"admin" in each app).
In r35 the various changes were made to port psn to the new Django admin
code. However, it now registers the admin classes in the models.py file.
This is bad practice and actually can cause difficult-to-diagnose crashes
when using the admin code. Basically, models files can be imported more
than once and duplicate admin registration goes badly, including leading to
circular import problems at times. You really don't want to have to handle
those bug reports (it will look like a django-psn problem because when
somebody removes django-psn, the problem will go away).
The recommended approach is to put admin classes and registration into an
admin.py file. This keeps it out of models.py and also means that anybody
using django-psn and admin.autodiscover() will have those admin classes
automatically registered (autodiscover() knows to look for a module called
"admin" in each app).
Sep 10, 2008
issue 2
(Some code cleanups and port to Django trunk) Status changed by leah.culver
- drackett made the suggested changes to move to Django 1.0. I've checked in the other
minor changes... let me know if I've missed any ;)
Status: Fixed
drackett made the suggested changes to move to Django 1.0. I've checked in the other
minor changes... let me know if I've missed any ;)
Status: Fixed
Sep 10, 2008
r36
(reformatted things for #2) committed by leah.culver
- reformatted things for #2
reformatted things for #2
Aug 11, 2008
issue 3
(43Things should be 43 Things) reported by leah.culver
- The title text for 43things should be "43 Things" not "43Things".
The title text for 43things should be "43 Things" not "43Things".
Aug 05, 2008
r35
(updating for newforms-admin branch merge with trunk.) committed by drackett
- updating for newforms-admin branch merge with trunk.
updating for newforms-admin branch merge with trunk.
Jul 28, 2008
issue 2
(Some code cleanups and port to Django trunk) reported by malc...@pointy-stick.com
- Two patches attached here.
The first one is some general code cleanup and fixes the misuse of
ugettext() (it should be ugettext_lazy() in model fields so that the
translation doesn't take place until the name is rendered). Also removes an
empty try...except I found (talking with Leah, she agreed it should just
go). There are some other cleanups that could be done in the view.py file,
but that isn't my focus just at the moment, so I'll come back to that.
The second patch applies on top of the first one and brings things forward
to support current Django trunk (and the recent 1.0-alpha) release. It adds
the psn/admin.py file and removes existing Admin usage in the models. Also
changes newforms -> forms to avoid a DeprecationWarning.
Two patches attached here.
The first one is some general code cleanup and fixes the misuse of
ugettext() (it should be ugettext_lazy() in model fields so that the
translation doesn't take place until the name is rendered). Also removes an
empty try...except I found (talking with Leah, she agreed it should just
go). There are some other cleanups that could be done in the view.py file,
but that isn't my focus just at the moment, so I'll come back to that.
The second patch applies on top of the first one and brings things forward
to support current Django trunk (and the recent 1.0-alpha) release. It adds
the psn/admin.py file and removes existing Admin usage in the models. Also
changes newforms -> forms to avoid a DeprecationWarning.
