My favorites | Sign in
Project Logo
                
Details: Show all Hide all

Earlier this year

  • Oct 06, 2009
    issue 31 (Inlines JavaScript error) commented on by nat...@playgroundblues.com   -   Look to http://github.com/nathanborror/django-basic-apps for a more recent version of the code.
    Look to http://github.com/nathanborror/django-basic-apps for a more recent version of the code.
  • Oct 06, 2009
    issue 31 (Inlines JavaScript error) commented on by ni28gm   -   SVN trunk and "Django Basic Apps 0.6.zip" still contain previous version of change_form.html.
    SVN trunk and "Django Basic Apps 0.6.zip" still contain previous version of change_form.html.
  • Sep 01, 2009
    issue 43 (issues arise with new posts and published status either clie...) reported by nodsworth   -   What steps will reproduce the problem? 1. create new post in the django admin with publish time of "now" 2. ensure server time is off or client time is incorrect (server in the past about 10 minutes in my case) 3. profit! no, just kidding. there is no 3rd step. What is the expected output? What do you see instead? A blog posting 10 minutes in the future shows up in the post_list view but does NOT show up in any of the views using date_based.* This means the blog posting shows up on the listing page but when viewing the post, a 404 is generated. Also, the month listing does not show the post. What version of the product are you using? On what operating system? 0.6 on python 2.5.2 with django 1.1.0 final Please provide any additional information below.
    What steps will reproduce the problem? 1. create new post in the django admin with publish time of "now" 2. ensure server time is off or client time is incorrect (server in the past about 10 minutes in my case) 3. profit! no, just kidding. there is no 3rd step. What is the expected output? What do you see instead? A blog posting 10 minutes in the future shows up in the post_list view but does NOT show up in any of the views using date_based.* This means the blog posting shows up on the listing page but when viewing the post, a 404 is generated. Also, the month listing does not show the post. What version of the product are you using? On what operating system? 0.6 on python 2.5.2 with django 1.1.0 final Please provide any additional information below.
  • Jul 11, 2009
    issue 42 ([enhancement] Packing with distutils) reported by brandon.konkle   -   In order to use django-basic-apps with virtualenv and pip, I needed to package it as a distutils distribution. This allows pip to automatically install the package to the virtual environment. To do this, I just moved all of the packages into a 'basic' subdirectory which acts as the master package, and then I created a setup.py file mostly copied from Django's own setup.py. I've included a diff here that you can try out. It looks massive, but that's just because I've moved everything to a subdirectory in order to play nice with distutils. I'd love to see this integrated into trunk so that I can install this as a pip --editable. Thanks! -Brandon
    In order to use django-basic-apps with virtualenv and pip, I needed to package it as a distutils distribution. This allows pip to automatically install the package to the virtual environment. To do this, I just moved all of the packages into a 'basic' subdirectory which acts as the master package, and then I created a setup.py file mostly copied from Django's own setup.py. I've included a diff here that you can try out. It looks massive, but that's just because I've moved everything to a subdirectory in order to play nice with distutils. I'd love to see this integrated into trunk so that I can install this as a pip --editable. Thanks! -Brandon
  • Jun 24, 2009
    issue 41 (Patch for passing extra params to the temples with the <inli...) commented on by juanjux   -   What disaster, I left the debug prints and pprints enabled, I'm attached the cleaned version of the patch
    What disaster, I left the debug prints and pprints enabled, I'm attached the cleaned version of the patch
  • Jun 24, 2009
    issue 41 (Patch for passing extra params to the temples with the <inli...) commented on by juanjux   -   Ups, sorry, I reported it as defect which obviously is not.
    Ups, sorry, I reported it as defect which obviously is not.
  • Jun 24, 2009
    issue 41 (Patch for passing extra params to the temples with the <inli...) reported by juanjux   -   Hi, I've modified a little the inlines parser.py to allow the option to use an aditional "extraparams" in the <inline> tag to give some extra parameters to the template context. For example, I'm using django-thumbnails (from djangothumbnails.com) and I use on my site: <inline type="dbmedia.image" id="1" extraparams="thumbnailsize:300x300,useframe:1" /> Patch attached.
    Hi, I've modified a little the inlines parser.py to allow the option to use an aditional "extraparams" in the <inline> tag to give some extra parameters to the template context. For example, I'm using django-thumbnails (from djangothumbnails.com) and I use on my site: <inline type="dbmedia.image" id="1" extraparams="thumbnailsize:300x300,useframe:1" /> Patch attached.
  • Jun 22, 2009
    issue 35 (django.templatetags.inlines when creating new post) commented on by bill...@serverspacesolutions.com.au   -   I found the INSTALLED_APPS instructions on the main page actually don't work as prescribed. I had to add all applications like 'basic.blog', 'basic.inlines', 'basic.books', etc.
    I found the INSTALLED_APPS instructions on the main page actually don't work as prescribed. I had to add all applications like 'basic.blog', 'basic.inlines', 'basic.books', etc.
  • Jun 22, 2009
    issue 29 (No <django.utils.functional.__proxy__ object) commented on by bill...@serverspacesolutions.com.au   -   I have the same error No <django.utils.functional.__proxy__ object at 0x90670cc> found for but PIL and PIL-devel didn't fix it. Happens on a post slug of a blog entry. Django Version (1, 0, 2, 'final', 0) Checked out 2 days ago: svn checkout http://django-basic-apps.googlecode.com/svn/trunk/ basic When I view categories the post belongs to, it's not listed but I haven't checked if the default templates include that by default.
    I have the same error No <django.utils.functional.__proxy__ object at 0x90670cc> found for but PIL and PIL-devel didn't fix it. Happens on a post slug of a blog entry. Django Version (1, 0, 2, 'final', 0) Checked out 2 days ago: svn checkout http://django-basic-apps.googlecode.com/svn/trunk/ basic When I view categories the post belongs to, it's not listed but I haven't checked if the default templates include that by default.
  • Jun 21, 2009
    issue 40 (Phone Number validates only against US) commented on by a...@alution.com   -   Sorry, logged in as the wrong user, commenting on this issue so I can receive email updates to an email address I actually check.
    Sorry, logged in as the wrong user, commenting on this issue so I can receive email updates to an email address I actually check.
  • Jun 21, 2009
    issue 40 (Phone Number validates only against US) reported by yout...@fearcauseeffect.com   -   What steps will reproduce the problem? 1. Create a phone number using correct notation for a country other than the USA. Ie, in Australia 03 9999 9999 2. Validation fails What is the expected output? What do you see instead? Validation should succeed because Australia is chosen as the country for the place. What version of the product are you using? On what operating system? trunk Please provide any additional information below. This is occuring because of http://code.google.com/p/django-basic-apps/source/browse/trunk/places/models.py#4 I think that possibly a custom field needs to be created call PhoneNumber which is country aware (this is something that I think should really be in localflavor anyway).
    What steps will reproduce the problem? 1. Create a phone number using correct notation for a country other than the USA. Ie, in Australia 03 9999 9999 2. Validation fails What is the expected output? What do you see instead? Validation should succeed because Australia is chosen as the country for the place. What version of the product are you using? On what operating system? trunk Please provide any additional information below. This is occuring because of http://code.google.com/p/django-basic-apps/source/browse/trunk/places/models.py#4 I think that possibly a custom field needs to be created call PhoneNumber which is country aware (this is something that I think should really be in localflavor anyway).
  • Jun 20, 2009
    issue 39 (syncdb doesn't create tables for all apps ) commented on by jeff.t.lindsey   -   this seems to be because basic apps doesn't use the current django truck new-forms admin, which requires a admin.py in each model and the registration of admin.site.register(MyModel, MyModelAdmin) to prefill forms in the admin. I've worked out the bugs in that, I believe and will be willing to share the updated code if there's a place I can put it.
    this seems to be because basic apps doesn't use the current django truck new-forms admin, which requires a admin.py in each model and the registration of admin.site.register(MyModel, MyModelAdmin) to prefill forms in the admin. I've worked out the bugs in that, I believe and will be willing to share the updated code if there's a place I can put it.
  • Jun 16, 2009
    issue 39 (syncdb doesn't create tables for all apps ) reported by jeff.t.lindsey   -   What steps will reproduce the problem? 1. Added basic with all subfolders to my project via SFTP 2. Added '<project_name>/basic.*' to my included apps 3. python2.5 manage.py syncdb What is the expected output? What do you see instead? Expected each app to create a table or multiple tables as necessary. However, only the inlines app created a table. The others were simply ignored What version of the product are you using? On what operating system? downloaded zip of basic.0.6 and placed via FTP. installed tagging module and BeautifulSoup module and put markup under installed apps. I'm running Django Trunk with mod_python 3.3.1, Python 2.5 on a Redhat box at Webfaction.com. Please provide any additional information below. If there are changes that need to be made to the individual models to make them work correctly, I didn't get that from the instructions. It seemed simple enough: make sure the required modules are in place, place in project, syncdb. Sorry.
    What steps will reproduce the problem? 1. Added basic with all subfolders to my project via SFTP 2. Added '<project_name>/basic.*' to my included apps 3. python2.5 manage.py syncdb What is the expected output? What do you see instead? Expected each app to create a table or multiple tables as necessary. However, only the inlines app created a table. The others were simply ignored What version of the product are you using? On what operating system? downloaded zip of basic.0.6 and placed via FTP. installed tagging module and BeautifulSoup module and put markup under installed apps. I'm running Django Trunk with mod_python 3.3.1, Python 2.5 on a Redhat box at Webfaction.com. Please provide any additional information below. If there are changes that need to be made to the individual models to make them work correctly, I didn't get that from the instructions. It seemed simple enough: make sure the required modules are in place, place in project, syncdb. Sorry.
  • Jun 15, 2009
    issue 38 (Need more documentation) Status changed by nat...@playgroundblues.com   -   I agree, patches accepted :)
    Status: Accepted
    I agree, patches accepted :)
    Status: Accepted
  • Jun 15, 2009
    issue 31 (Inlines JavaScript error) Status changed by nat...@playgroundblues.com   -   Thanks rich, this is fixed: http://github.com/nathanborror/django-basic- apps/commit/2817813634a5b800fd2d56ca5491d6bedeee9ec7
    Status: Fixed
    Thanks rich, this is fixed: http://github.com/nathanborror/django-basic- apps/commit/2817813634a5b800fd2d56ca5491d6bedeee9ec7
    Status: Fixed
  • Jun 15, 2009
    issue 13 (TemplateSyntaxError - Invalid block tag: 'get_inline_types') commented on by nat...@playgroundblues.com   -   Be sure and run syncdb after installing inlines. The tag relies on a table 'inline_types' to be in the db. This tag is only used for the custom change_form.html in the admin, it really has no outside use. Let me know if that fixes the problem.
    Be sure and run syncdb after installing inlines. The tag relies on a table 'inline_types' to be in the db. This tag is only used for the custom change_form.html in the admin, it really has no outside use. Let me know if that fixes the problem.
  • Jun 12, 2009
    issue 13 (TemplateSyntaxError - Invalid block tag: 'get_inline_types') commented on by shac...@berkeley.edu   -   I'm suddenly getting this error as well, after it having worked for years. basic.inlines is installed. At first I thought it might be a namespace conflict because I recently installed django_inlines, but doesn't seem to be - I can uninstall django_inlines and the error persists. I commented out this line in the template blog/post/change_form.html: content += '{#% get_inline_types as inline_list %#}' and everything seems to be working fine, though I'm not sure what I'm missing by having that gone.
    I'm suddenly getting this error as well, after it having worked for years. basic.inlines is installed. At first I thought it might be a namespace conflict because I recently installed django_inlines, but doesn't seem to be - I can uninstall django_inlines and the error persists. I commented out this line in the template blog/post/change_form.html: content += '{#% get_inline_types as inline_list %#}' and everything seems to be working fine, though I'm not sure what I'm missing by having that gone.
  • Jun 07, 2009
    issue 38 (Need more documentation) reported by mayuresh   -   Need more documentation about what each app can do and some examples for using the app.
    Need more documentation about what each app can do and some examples for using the app.
  • Apr 11, 2009
    issue 37 (blog search and category_detail views do not accept extra_co...) reported by ltaylor.volks   -   It is sometimes useful to pass an extra context through to your templates without having to modify the stock views e.g. this include will pass the dict including the extra_context to each blog view (r'^blog/', include('basic.blog.urls'), dict(extra_context={'nav_here':'nav_blog'})), Issues: 1. category_detail view provides its own extra_context so if you pass it your own via your urlpattern, the generic view will complain: TypeError: object_list() got multiple values for keyword argument 'extra_context' 2. search view does not provide for **kwargs at all, so it is impossible to pass extra_context via the url. Attached patch updates the extra_context dict in both views so it passes through to rendered templates.
    It is sometimes useful to pass an extra context through to your templates without having to modify the stock views e.g. this include will pass the dict including the extra_context to each blog view (r'^blog/', include('basic.blog.urls'), dict(extra_context={'nav_here':'nav_blog'})), Issues: 1. category_detail view provides its own extra_context so if you pass it your own via your urlpattern, the generic view will complain: TypeError: object_list() got multiple values for keyword argument 'extra_context' 2. search view does not provide for **kwargs at all, so it is impossible to pass extra_context via the url. Attached patch updates the extra_context dict in both views so it passes through to rendered templates.
  • Mar 07, 2009
    issue 36 (slugs should be set to unique=True for media app (Video, Pho...) reported by skylar.saveland   -   What steps will reproduce the problem? 1. Save two videos with the same slug. 2. request the object_detaili for one of the videos What is the expected output? What do you see instead? Well, if the slugs were kept unique then it wouldn't be a problem, but since I was allowed to save two videos with the same slug: MultipleObjectsReturned get() returned more than one Video -- it returned 2! Lookup parameters were {} What version of the product are you using? On what operating system? trunk, trunk, ubuntu 8.10 Please provide any additional information below. A simple fix, I don't know if it is significant enough to merit a change.
    What steps will reproduce the problem? 1. Save two videos with the same slug. 2. request the object_detaili for one of the videos What is the expected output? What do you see instead? Well, if the slugs were kept unique then it wouldn't be a problem, but since I was allowed to save two videos with the same slug: MultipleObjectsReturned get() returned more than one Video -- it returned 2! Lookup parameters were {} What version of the product are you using? On what operating system? trunk, trunk, ubuntu 8.10 Please provide any additional information below. A simple fix, I don't know if it is significant enough to merit a change.
  • Feb 22, 2009
    issue 35 (django.templatetags.inlines when creating new post) commented on by jstump   -   I was missing the 'basic.inlines' in my INSTALLED_APPS. Should probably add this to your documentation so others don't get confused. Someone in #django told me to just nuke the admin templates.
    I was missing the 'basic.inlines' in my INSTALLED_APPS. Should probably add this to your documentation so others don't get confused. Someone in #django told me to just nuke the admin templates.
  • Feb 22, 2009
    issue 35 (django.templatetags.inlines when creating new post) reported by jstump   -   I did a fresh checkout today (r102 I'm guessing) and installed it into my Python path. All loaded up fine after syncing the DB, etc. except when I went to create a new post I got an error about django.templatetags.inlines missing. A quick look in django/templatetags shows that there isn't an inlines.py. I don't see one in Django's trunk either. I fixed it, temporarily, by removing blog's admin templates.
    I did a fresh checkout today (r102 I'm guessing) and installed it into my Python path. All loaded up fine after syncing the DB, etc. except when I went to create a new post I got an error about django.templatetags.inlines missing. A quick look in django/templatetags shows that there isn't an inlines.py. I don't see one in Django's trunk either. I fixed it, temporarily, by removing blog's admin templates.
  • Feb 19, 2009
    issue 1 (Wrong URLs in the Blog app.) commented on by yanchenko.igor   -   hello, I'm write filter "cdate" which return month in "C"-locale, and I use it instead "date" P.S. sorry for my english
    hello, I'm write filter "cdate" which return month in "C"-locale, and I use it instead "date" P.S. sorry for my english
  • Feb 15, 2009
    issue 9 (blog.models.Post.slug is not a unique field, duplicate slugs...) commented on by mandric   -   Is this really fixed? I think the problem is that the publish field is a datetime object so it's almost always unique. If you want to make sure the URL is unique you need to use a DateField instead of DateTime Field. Otherwise you haven't solved the MultipleObjectsReturned problem. In [23]: from basic.blog.models import Post In [24]: from django.contrib.auth.models import User In [25]: u=User.objects.all()[0] In [26]: from datetime import datetime In [27]: q=Post(title='foobar',slug='fbar',author=u,publish=datetime.now()) In [28]: p=Post(title='foobar',slug='fbar',author=u,publish=datetime.now()) In [29]: q.save() In [30]: p.save() In [31]: Post.objects.get(slug='fbar') --------------------------------------------------------------------------- MultipleObjectsReturned Traceback (most recent call last) /Users/mandric/dev/jschool/code/projects/kdmc/<ipython console> in <module>() /opt/local/lib/python2.5/site-packages/django/db/models/manager.py in get(self, *args, **kwargs) 91 92 def get(self, *args, **kwargs): ---> 93 return self.get_query_set().get(*args, **kwargs) 94 95 def get_or_create(self, **kwargs): /opt/local/lib/python2.5/site-packages/django/db/models/query.py in get(self, *args, **kwargs) 309 % self.model._meta.object_name) 310 raise self.model.MultipleObjectsReturned("get() returned more than one %s -- it returned %s! Lookup parameters were %s" --> 311 % (self.model._meta.object_name, num, kwargs)) 312 313 def create(self, **kwargs): MultipleObjectsReturned: get() returned more than one Post -- it returned 2! Lookup parameters were {'slug': 'fbar'}
    Is this really fixed? I think the problem is that the publish field is a datetime object so it's almost always unique. If you want to make sure the URL is unique you need to use a DateField instead of DateTime Field. Otherwise you haven't solved the MultipleObjectsReturned problem. In [23]: from basic.blog.models import Post In [24]: from django.contrib.auth.models import User In [25]: u=User.objects.all()[0] In [26]: from datetime import datetime In [27]: q=Post(title='foobar',slug='fbar',author=u,publish=datetime.now()) In [28]: p=Post(title='foobar',slug='fbar',author=u,publish=datetime.now()) In [29]: q.save() In [30]: p.save() In [31]: Post.objects.get(slug='fbar') --------------------------------------------------------------------------- MultipleObjectsReturned Traceback (most recent call last) /Users/mandric/dev/jschool/code/projects/kdmc/<ipython console> in <module>() /opt/local/lib/python2.5/site-packages/django/db/models/manager.py in get(self, *args, **kwargs) 91 92 def get(self, *args, **kwargs): ---> 93 return self.get_query_set().get(*args, **kwargs) 94 95 def get_or_create(self, **kwargs): /opt/local/lib/python2.5/site-packages/django/db/models/query.py in get(self, *args, **kwargs) 309 % self.model._meta.object_name) 310 raise self.model.MultipleObjectsReturned("get() returned more than one %s -- it returned %s! Lookup parameters were %s" --> 311 % (self.model._meta.object_name, num, kwargs)) 312 313 def create(self, **kwargs): MultipleObjectsReturned: get() returned more than one Post -- it returned 2! Lookup parameters were {'slug': 'fbar'}
  • Feb 01, 2009
    r102 (Fixed fans list) committed by nat...@playgroundblues.com   -   Fixed fans list
    Fixed fans list
  • Jan 31, 2009
    issue 34 (events: get_upcoming_events template tag) commented on by sebnow   -   There was a small bug in the template tag - it didn't return an empty string so "None" shows up in the template output. Patch is attached. Sorry :P.
    There was a small bug in the template tag - it didn't return an empty string so "None" shows up in the template output. Patch is attached. Sorry :P.
  • Jan 30, 2009
    issue 34 (events: get_upcoming_events template tag) changed by nat...@playgroundblues.com   -   Thank you for your contribution. It has been added :)
    Status: Fixed
    Labels: Type-Enhancement Type-Defect
    Thank you for your contribution. It has been added :)
    Status: Fixed
    Labels: Type-Enhancement Type-Defect
  • Jan 30, 2009
    r101 (Adding 'get_upcoming_events' template tag) committed by nat...@playgroundblues.com   -   Adding 'get_upcoming_events' template tag
    Adding 'get_upcoming_events' template tag
  • Jan 30, 2009
    issue 34 (events: get_upcoming_events template tag) reported by sebnow   -   It would be nice to be able to get upcoming events using a template tag. I wrote a rough version of it, but it doesn't make much sense to get EventTime instances from "get_upcoming_events". Example: {% get_upcoming_events 10 as upcoming_events %} The attached events.py should go in basic/events/templatetags/
    It would be nice to be able to get upcoming events using a template tag. I wrote a rough version of it, but it doesn't make much sense to get EventTime instances from "get_upcoming_events". Example: {% get_upcoming_events 10 as upcoming_events %} The attached events.py should go in basic/events/templatetags/
  • Jan 27, 2009
    issue 32 (Missing file bookmark_list.html in sources) reported by yustoss   -   In sources of bookmarks application (rev. 100) missing file bookmarks\templates\bookmarks\bookmark_list.html. Exception Type: TemplateDoesNotExist at /bookmarks/ Exception Value: bookmarks/bookmark_list.html
    In sources of bookmarks application (rev. 100) missing file bookmarks\templates\bookmarks\bookmark_list.html. Exception Type: TemplateDoesNotExist at /bookmarks/ Exception Value: bookmarks/bookmark_list.html
  • Jan 25, 2009
    issue 31 (Inlines JavaScript error) reported by richardcornish   -   What steps will reproduce the problem? 1. Open Firefox. 2. Add a blog post. 3. Inlines menu does not appear What is the expected output? What do you see instead? The Inlines menu should appear when adding a blog post, but it doesn't. In Safari, the Inlines menu does appear (which means it's probably more forgiving to JavaScript errors), but Firefox complains and fails to show the menu. The insertBefore DOM method requires two arguments: the element to be inserted and the element that appears afterward. The second argument can be null, but it must be there. I've attached a patch that emulates an "insertAfter" method. I've tested this on my own checkout, and it solves the problem. See https://developer.mozilla.org/en/DOM/element.insertBefore. What version of the product are you using? On what operating system? Django trunk, django-basic-apps trunk.
    What steps will reproduce the problem? 1. Open Firefox. 2. Add a blog post. 3. Inlines menu does not appear What is the expected output? What do you see instead? The Inlines menu should appear when adding a blog post, but it doesn't. In Safari, the Inlines menu does appear (which means it's probably more forgiving to JavaScript errors), but Firefox complains and fails to show the menu. The insertBefore DOM method requires two arguments: the element to be inserted and the element that appears afterward. The second argument can be null, but it must be there. I've attached a patch that emulates an "insertAfter" method. I've tested this on my own checkout, and it solves the problem. See https://developer.mozilla.org/en/DOM/element.insertBefore. What version of the product are you using? On what operating system? Django trunk, django-basic-apps trunk.
  • Jan 23, 2009
    issue 29 (No <django.utils.functional.__proxy__ object) Status changed by nat...@playgroundblues.com   -   It sounds like this is a problem on your end. Do you have an app that requires PIL (Python Image Library)? Currently none of the Basic Apps require PIL.
    Status: WontFix
    It sounds like this is a problem on your end. Do you have an app that requires PIL (Python Image Library)? Currently none of the Basic Apps require PIL.
    Status: WontFix
  • Jan 23, 2009
    issue 25 (blog app should list 'inlines' in README as a dependency) Status changed by nat...@playgroundblues.com   -  
    Status: Fixed
    Status: Fixed
  • Jan 23, 2009
    r100 (Added 'inlines' as a dependency) committed by nat...@playgroundblues.com   -   Added 'inlines' as a dependency
    Added 'inlines' as a dependency
  • Jan 23, 2009
    issue 26 (media/urls/photos.py has outdated import statment and query) Status changed by nat...@playgroundblues.com   -   Fixed, thank you!
    Status: Fixed
    Fixed, thank you!
    Status: Fixed
  • Jan 23, 2009
    r99 (Fixed import error) committed by nat...@playgroundblues.com   -   Fixed import error
    Fixed import error
  • Jan 23, 2009
    issue 27 ([blog] post manager filters) Status changed by nat...@playgroundblues.com   -   I believe this has been fixed.
    Status: Fixed
    I believe this has been fixed.
    Status: Fixed
  • Jan 12, 2009
    issue 30 (No email field for people or profiles) Status changed by nat...@playgroundblues.com   -   You can add an email address to a User object. You could very easily add an email field to the Person object.
    Status: WontFix
    You can add an email address to a User object. You could very easily add an email field to the Person object.
    Status: WontFix
  • Jan 12, 2009
    issue 30 (No email field for people or profiles) reported by colin.powell   -   Why is there no way to add email addresses to people, either via their profiles or via the Person model? Seems like a major oversight.
    Why is there no way to add email addresses to people, either via their profiles or via the Person model? Seems like a major oversight.
  • Jan 10, 2009
    r98 (Removing the follow email logic and template. This is better...) committed by nat...@playgroundblues.com   -   Removing the follow email logic and template. This is better suited as a signal someplace else.
    Removing the follow email logic and template. This is better suited as a signal someplace else.
  • Jan 03, 2009
    issue 28 (Django 1.0 compatibilty) Status changed by nat...@playgroundblues.com   -  
    Status: Invalid
    Status: Invalid
  • Jan 03, 2009
    issue 28 (Django 1.0 compatibilty) commented on by flavio.curella   -   Everything is still pre-NFA code
    Everything is still pre-NFA code
  • Jan 01, 2009
    issue 29 (No <django.utils.functional.__proxy__ object) reported by m.malmros   -   1. install basic blog on django (ver 1.0.2) 2. posting to the blog generated the following: No <django.utils.functional.__proxy__ object 2. to solve :requires python-imaging AND python-imaging-dbg 3. this issue is discussed in part at http://groups.google.com/group/pinax-users/browse_thread/thread/7c3eacc5c40f4c11?pli=1
    1. install basic blog on django (ver 1.0.2) 2. posting to the blog generated the following: No <django.utils.functional.__proxy__ object 2. to solve :requires python-imaging AND python-imaging-dbg 3. this issue is discussed in part at http://groups.google.com/group/pinax-users/browse_thread/thread/7c3eacc5c40f4c11?pli=1

Older

  • Dec 23, 2008
    issue 28 (Django 1.0 compatibilty) commented on by flavio.curella   -   basic-people is still pre-NFA code
    basic-people is still pre-NFA code
  • Dec 21, 2008
    issue 28 (Django 1.0 compatibilty) commented on by nat...@playgroundblues.com   -   Can you provide an explanation of these errors?
    Can you provide an explanation of these errors?
  • Dec 21, 2008
    issue 28 (Django 1.0 compatibilty) reported by tkuntario   -   What steps will reproduce the problem? - Use these apps with Django 1.0.x What is the expected output? What do you see instead? - Currently I find errors in models and admin area. Maybe there are more but I haven't found it all. What version of the product are you using? On what operating system? 1. basic-apps trunk version. 2. Django 1.0.2 3. Python 2.5.1 4. Mac OS 10.5
    What steps will reproduce the problem? - Use these apps with Django 1.0.x What is the expected output? What do you see instead? - Currently I find errors in models and admin area. Maybe there are more but I haven't found it all. What version of the product are you using? On what operating system? 1. basic-apps trunk version. 2. Django 1.0.2 3. Python 2.5.1 4. Mac OS 10.5
  • Dec 20, 2008
    r97 (Added 'fans' to relationship list manager) committed by nat...@playgroundblues.com   -   Added 'fans' to relationship list manager
    Added 'fans' to relationship list manager
  • Nov 27, 2008
    issue 17 (ImportError: No module named dateutil /people/models.py) commented on by pilypala   -   #Following solves this issue in ubuntu 8.04 server edition sudo apt-get install python-dateutil
    #Following solves this issue in ubuntu 8.04 server edition sudo apt-get install python-dateutil
  • Nov 27, 2008
    issue 17 (ImportError: No module named dateutil /people/models.py) commented on by pilypala   -   Looks like python 2.5.2 that came with ubuntu 8.04 server doesn't have this dateutil pre installed.
    Looks like python 2.5.2 that came with ubuntu 8.04 server doesn't have this dateutil pre installed.
  • Nov 27, 2008
    issue 27 ([blog] post manager filters) reported by yatiohi   -   PostManager.published() expected behaviour is to return posts with published time before now. The thing is that the filter_dict that is used for filtering Posts is evaluated on the PostManager.__init__() method instead of the published() method causing weird behaviour: from basic.blog import Post Post.objects.published() #create a new post Post.objects.published() does not include the new post because filter_dict is already evaluated.
    PostManager.published() expected behaviour is to return posts with published time before now. The thing is that the filter_dict that is used for filtering Posts is evaluated on the PostManager.__init__() method instead of the published() method causing weird behaviour: from basic.blog import Post Post.objects.published() #create a new post Post.objects.published() does not include the new post because filter_dict is already evaluated.
 
Hosted by Google Code