django-forum - Project Hosting on Google Code

Last 7 days Dec 21, 2009 issue 82 (Port to GAE/Django) changed by rwpoulton - If somebody submits a patch to make django-forum work with GAE, I'll be happy to accept it but ONLY if it doesn't change functionality of the core product. Until then I will be closing this issue. Status: WontFix Labels: Type-Enhancement Priority-Low −Type-Defect −Priority-Medium If somebody submits a patch to make django-forum work with GAE, I'll be happy to accept it but ONLY if it doesn't change functionality of the core product. Until then I will be closing this issue. Status: WontFix Labels: Type-Enhancement Priority-Low −Type-Defect −Priority-Medium Dec 21, 2009 issue 85 (Template error and auth_logout) Status changed by rwpoulton - Status: Invalid Status: Invalid Dec 20, 2009 issue 85 (Template error and auth_logout) commented on by rishisingh - Wow, I'm stupid. I posted this on the wrong site. I apologize. Wow, I'm stupid. I posted this on the wrong site. I apologize. Dec 20, 2009 issue 85 (Template error and auth_logout) reported by rishisingh - What steps will reproduce the problem? 1. Loading website at /forumBR/ 2. 3. What is the expected output? What do you see instead? Was hoping to see the website What version of the product are you using? On what operating system? Latest Beta version Please provide any additional information below. Caught an exception while rendering: Reverse for 'collegiateinvestor.auth_logout' with arguments '()' and keyword arguments '{}' not found. 57 <a href="{% url forum-index %}" 58 title='{% trans "Check out our beatiful homepage" %}'> 59 {% trans "Home" %}</a> 60 61 <a href='{% url forum-search %}' 62 title='{% trans "Looking for something?" %}'> 63 {% trans "Search" %}</a> 64 65 {% if user.is_authenticated %} 66 67 <a href="{% url auth_logout %}?next={% url forum-index %}" 68 title='{% trans "Logout from website" %}'> 69 {% trans "Sign Out" %}</a> 70 71 <a href='{% url forum-user-profile user.username %}' 72 title='{{user.username}} : {% trans "View your personal data" %}'> 73 {{user}}</a> 74 75 {% if user.is_staff %} 76 : <a href='{% url admin:index %}' title='{% trans "Administrative panel" %}'>Admin</a> 77 : <a href='{% url admin:forum_forum_changelist %}'>Forum</a> What steps will reproduce the problem? 1. Loading website at /forumBR/ 2. 3. What is the expected output? What do you see instead? Was hoping to see the website What version of the product are you using? On what operating system? Latest Beta version Please provide any additional information below. Caught an exception while rendering: Reverse for 'collegiateinvestor.auth_logout' with arguments '()' and keyword arguments '{}' not found. 57 <a href="{% url forum-index %}" 58 title='{% trans "Check out our beatiful homepage" %}'> 59 {% trans "Home" %}</a> 60 61 <a href='{% url forum-search %}' 62 title='{% trans "Looking for something?" %}'> 63 {% trans "Search" %}</a> 64 65 {% if user.is_authenticated %} 66 67 <a href="{% url auth_logout %}?next={% url forum-index %}" 68 title='{% trans "Logout from website" %}'> 69 {% trans "Sign Out" %}</a> 70 71 <a href='{% url forum-user-profile user.username %}' 72 title='{{user.username}} : {% trans "View your personal data" %}'> 73 {{user}}</a> 74 75 {% if user.is_staff %} 76 : <a href='{% url admin:index %}' title='{% trans "Administrative panel" %}'>Admin</a> 77 : <a href='{% url admin:forum_forum_changelist %}'>Forum</a> Last 30 days Nov 30, 2009 issue 63 (Display new/unread posts) commented on by slav0n...@gmail.com - Hello, Djangobb not mature project, but you can saw as it done :http://hg.djangobb.org/djangobb/rev/ddfffe696aa8 (but checking unreaded forums not correct, i checked only last added post status), PunBB use cookies for this. Hello, Djangobb not mature project, but you can saw as it done :http://hg.djangobb.org/djangobb/rev/ddfffe696aa8 (but checking unreaded forums not correct, i checked only last added post status), PunBB use cookies for this. Earlier this year Nov 02, 2009 issue 84 (MArkDown must be pre-installed? ) commented on by bymenda - Hi Michele. Those lines should not be removed because for example, on the server that I'm using now for my clients (Webfaction) doesn't have Markdown installed, and it has a Django installation in it. I agree with you that it should be included in the How-To. Hi Michele. Those lines should not be removed because for example, on the server that I'm using now for my clients (Webfaction) doesn't have Markdown installed, and it has a Django installation in it. I agree with you that it should be included in the How-To. Oct 30, 2009 issue 84 (MArkDown must be pre-installed? ) reported by michele.pasin - If yes, maybe you want to state it in the how-to page too! I couldn't run the forum with out installing markdown first, and I got it here (never used it before): http://www.freewisdom.org/projects/python-markdown/Installation Although on the same site I read that markdown comes with django... in that case you might wanna change these lines: try: from markdown import markdown except ImportError: class MarkdownNotFound(Exception): def __str__(self): return "Markdown is not installed!" raise MarkdownNotFound thanks! If yes, maybe you want to state it in the how-to page too! I couldn't run the forum with out installing markdown first, and I got it here (never used it before): http://www.freewisdom.org/projects/python-markdown/Installation Although on the same site I read that markdown comes with django... in that case you might wanna change these lines: try: from markdown import markdown except ImportError: class MarkdownNotFound(Exception): def __str__(self): return "Markdown is not installed!" raise MarkdownNotFound thanks! Oct 16, 2009 issue 83 (site's sitemap will conflict with django-forum sitemap) reported by askfor - What steps will reproduce the problem? 1. in urls.py from django.contrib.sitemaps import views as sitemap_views (r'^sitemap.xml$',sitemap_views.index, {'sitemaps': sitemaps}), (r'^sitemap-(?P<section>.+)\.xml$',sitemap_views.sitemap, {'sitemaps': sitemaps}), (r'^forum/', include('forum.urls')), 2. vists www.example.com/sitemap.xml What is the expected output? What do you see instead? the url in sitemap.xml will be "www.example.com/forum/sitemap- section.xml " but it should be " www.example.com/sitemap-section.xml What version of the product are you using? On what operating system? django 1.1 Please provide any additional information below. i'm not sure if this's the problem of django-forum. since django.contrib.sitemap use 'django.contrib.sitemaps.views.sitemap' for the url reversing. What steps will reproduce the problem? 1. in urls.py from django.contrib.sitemaps import views as sitemap_views (r'^sitemap.xml$',sitemap_views.index, {'sitemaps': sitemaps}), (r'^sitemap-(?P<section>.+)\.xml$',sitemap_views.sitemap, {'sitemaps': sitemaps}), (r'^forum/', include('forum.urls')), 2. vists www.example.com/sitemap.xml What is the expected output? What do you see instead? the url in sitemap.xml will be "www.example.com/forum/sitemap- section.xml " but it should be " www.example.com/sitemap-section.xml What version of the product are you using? On what operating system? django 1.1 Please provide any additional information below. i'm not sure if this's the problem of django-forum. since django.contrib.sitemap use 'django.contrib.sitemaps.views.sitemap' for the url reversing. Oct 12, 2009 issue 82 (Port to GAE/Django) commented on by bymenda - I think that it will be pretty difficult to port it and the admin should be written because with GAE you can't use the Django Admin. Maintaining two different versions of the same application is a hard task. I don't know if someone is interested in making a port. I think that it will be pretty difficult to port it and the admin should be written because with GAE you can't use the Django Admin. Maintaining two different versions of the same application is a hard task. I don't know if someone is interested in making a port. Oct 06, 2009 issue 82 (Port to GAE/Django) reported by a...@txm.net - Could this be ported to Google AppEngine's version of Django? Could this be ported to Google AppEngine's version of Django? Oct 01, 2009 issue 81 (Breadcrumb cusomization) reported by djmuhlestein - It would be nice if the breadcrumbs were separated out to be their own template and tag instead of part of each page template. It's difficult to integrate forum into a broader site that already has navigation links without changing every forum template. Thanks! It would be nice if the breadcrumbs were separated out to be their own template and tag instead of part of each page template. It's difficult to integrate forum into a broader site that already has navigation links without changing every forum template. Thanks! Sep 28, 2009 issue 80 (newthread rudimentary function fix) reported by bymenda - I fixed the rudimentary old newthread function to a better maintainable one. It took me a long time to discover how to do that, but reading documentation and other people's code I realized that forms can have a "prefix" argument. I've split the big form in 3 independent partialforms which use the existing models. By the way I fixed one error that caused the rendering template to fail in "newthread.html". I generated the patch with "git diff" because I don't use svn. Anyways I think that the result file is the same than if I did it with "svn diff". Greetings from Spain, Rafa Muñoz Cárdenas. I fixed the rudimentary old newthread function to a better maintainable one. It took me a long time to discover how to do that, but reading documentation and other people's code I realized that forms can have a "prefix" argument. I've split the big form in 3 independent partialforms which use the existing models. By the way I fixed one error that caused the rendering template to fail in "newthread.html". I generated the patch with "git diff" because I don't use svn. Anyways I think that the result file is the same than if I did it with "svn diff". Greetings from Spain, Rafa Muñoz Cárdenas. Sep 28, 2009 issue 78 (A little change to ThreadPostDetails) commented on by bymenda - Discard this issue, please. Discard this issue, please. Sep 15, 2009 issue 79 (setuptools doesn't copy templates to forum packages.) commented on by djmuhlestein - Needs 'templates/forum/.txt' as well for the notify.txt file. Needs 'templates/forum/.txt' as well for the notify.txt file. Sep 15, 2009 issue 79 (setuptools doesn't copy templates to forum packages.) reported by djmuhlestein - What steps will reproduce the problem? 1. python setup.py install What is the expected output? What do you see instead? /path/to/python/site-packages/forumpath/forum/templates The templates are not found by find_packages because they aren't a python package. What version of the product are you using? On what operating system? r54 Please provide any additional information below. Adding this to setup.py seems to fix the issue: --- setup.py (revision 54) +++ setup.py (working copy) @@ -30,6 +30,7 @@ url='http://code.google.com/p/django-forum/', license='BSD', packages=find_packages(), + package_data={'forum':['templates/.html', 'templates/forum/.html','templates/forum/feeds/.html']}, include_package_data=True, zip_safe=False, install_requires=['setuptools'], There is probably an easier way to search for the templates though without explicitly naming them. What steps will reproduce the problem? 1. python setup.py install What is the expected output? What do you see instead? /path/to/python/site-packages/forumpath/forum/templates The templates are not found by find_packages because they aren't a python package. What version of the product are you using? On what operating system? r54 Please provide any additional information below. Adding this to setup.py seems to fix the issue: --- setup.py (revision 54) +++ setup.py (working copy) @@ -30,6 +30,7 @@ url='http://code.google.com/p/django-forum/', license='BSD', packages=find_packages(), + package_data={'forum':['templates/.html', 'templates/forum/.html','templates/forum/feeds/.html']}, include_package_data=True, zip_safe=False, install_requires=['setuptools'], There is probably an easier way to search for the templates though without explicitly naming them. Sep 10, 2009 issue 76 (Changing New thread's position) commented on by bymenda - It's easy to be changed by anyone, but if it's the best way to have a better usability, I don't understand why we should not change it. The entry barrier is still low with this change (it's just replacing a form for a link). The current way to post a new thread is confusing to the user because everyone is used to post threads like I say in every existing forum in the internet. Why we should change that if it's the best way to do it and it works? Bad designs lead to confusion, and in my humble oppinion this is a bad design. It's easy to be changed by anyone, but if it's the best way to have a better usability, I don't understand why we should not change it. The entry barrier is still low with this change (it's just replacing a form for a link). The current way to post a new thread is confusing to the user because everyone is used to post threads like I say in every existing forum in the internet. Why we should change that if it's the best way to do it and it works? Bad designs lead to confusion, and in my humble oppinion this is a bad design. Sep 10, 2009 issue 78 (A little change to ThreadPostDetails) changed by rwpoulton - Can you please explain the changes being made here? If it's in preparation for other changes, I'd rather wait for those other changes rather than just drip-feeding small modifications into the codebase. Owner: rwpoulton Labels: Type-Enhancement −Type-Defect Can you please explain the changes being made here? If it's in preparation for other changes, I'd rather wait for those other changes rather than just drip-feeding small modifications into the codebase. Owner: rwpoulton Labels: Type-Enhancement −Type-Defect Sep 10, 2009 issue 76 (Changing New thread's position) changed by rwpoulton - I don't think we need to remove this from the thread listing; it is something that is very easy for a site owner to do if they have a need. I believe for the default templates we should have the lowest barrier to entry possible. Status: WontFix Owner: rwpoulton I don't think we need to remove this from the thread listing; it is something that is very easy for a site owner to do if they have a need. I believe for the default templates we should have the lowest barrier to entry possible. Status: WontFix Owner: rwpoulton Sep 03, 2009 issue 75 (Evolving forums) commented on by bymenda - OK, it's a good valid point of view. My support for the idea. OK, it's a good valid point of view. My support for the idea. Sep 03, 2009 issue 77 (Don't do anything if nobody subscribed the thread) changed by rwpoulton - Good suggestion; added in SVN r54. Thanks! Status: Fixed Owner: rwpoulton Good suggestion; added in SVN r54. Thanks! Status: Fixed Owner: rwpoulton Sep 03, 2009 r54 (Fixes issue #77: Don't process subscription code if there ar...) committed by rwpoulton - Fixes issue #77 : Don't process subscription code if there aren't any subscriptions to the thread. Fixes issue #77 : Don't process subscription code if there aren't any subscriptions to the thread. Sep 03, 2009 issue 75 (Evolving forums) commented on by rwpoulton - IMO if we can make life easier for people using 3rd party software with relatively little effort on our part, we should do so. Not saying that always making fields 'null=True' is a good thing; just that we should try and be responsible netizens. IMO if we can make life easier for people using 3rd party software with relatively little effort on our part, we should do so. Not saying that always making fields 'null=True' is a good thing; just that we should try and be responsible netizens. Sep 03, 2009 issue 42 (Not compatible with setuptools) Status changed by rwpoulton - Committed in SVN r53. Thanks for the gentle prod :) Note to users that django-forum/forum/ must now be in your PYTHONPATH rather than just forum/. Status: Done Committed in SVN r53. Thanks for the gentle prod :) Note to users that django-forum/forum/ must now be in your PYTHONPATH rather than just forum/. Status: Done Sep 03, 2009 issue 75 (Evolving forums) commented on by bymenda - Hi Ross. It's a good solution but only temporarily and for special migration cases. If we want our application to be strong to failures it should be null. If something bad happens creating a message then we may have a null body_html field, and this is the last thing we want. Hi Ross. It's a good solution but only temporarily and for special migration cases. If we want our application to be strong to failures it should be null. If something bad happens creating a message then we may have a null body_html field, and this is the last thing we want. Sep 03, 2009 r53 (Issue #42: Make compatible with setuptools. Note that you n...) committed by rwpoulton - Issue #42 : Make compatible with setuptools. Note that you now need to make sure forum/forum is in your PYTHONPATH rather than just forum/. Thanks to Dan Fairs for this suggestion. Issue #42 : Make compatible with setuptools. Note that you now need to make sure forum/forum is in your PYTHONPATH rather than just forum/. Thanks to Dan Fairs for this suggestion. Sep 03, 2009 issue 75 (Evolving forums) commented on by fericean - From my point of view if the added fields have default values or can be null then the models can be migrated easily. I have a django-forum in production but when you commit some changes I try them first in a staging area so if I see any problems I'll let you know together with my proposed solution. So thanks a lot and keep up the good work, Radu Fericean from Romania :) From my point of view if the added fields have default values or can be null then the models can be migrated easily. I have a django-forum in production but when you commit some changes I try them first in a staging area so if I see any problems I'll let you know together with my proposed solution. So thanks a lot and keep up the good work, Radu Fericean from Romania :) Sep 03, 2009 issue 75 (Evolving forums) changed by rwpoulton - Hi fericean, I'll take your suggestion on board: Rather than making a field non-null if it's being added after the rest of the model, we'll try to make it 'null=True' in models.py. In this example it wouldn't have made a difference to the actual application and would have made your life easier. Are there any other guidelines we should be trying to follow? Keeping in mind that this is an in-progress application rather than a stable release. Status: Done Owner: rwpoulton Hi fericean, I'll take your suggestion on board: Rather than making a field non-null if it's being added after the rest of the model, we'll try to make it 'null=True' in models.py. In this example it wouldn't have made a difference to the actual application and would have made your life easier. Are there any other guidelines we should be trying to follow? Keeping in mind that this is an in-progress application rather than a stable release. Status: Done Owner: rwpoulton Sep 03, 2009 issue 75 (Evolving forums) commented on by bymenda - Oh yeah, shit happens! :D Well, I don't know if there's a better solution for django-evolution users. For now we have the rudimentary methods which at least work. Oh yeah, shit happens! :D Well, I don't know if there's a better solution for django-evolution users. For now we have the rudimentary methods which at least work. Sep 03, 2009 issue 42 (Not compatible with setuptools) commented on by xphuture - I've done it in a Mercurial version if you need it : http://bitbucket.org/jibaku/django-forum/ I've done it in a Mercurial version if you need it : http://bitbucket.org/jibaku/django-forum/ Sep 03, 2009 issue 75 (Evolving forums) commented on by fericean - I don't want body_html to be null but I am using django-evolution (alternative to south or dmigrations). This is why I did not write the ALTER commands described in your README.txt. In this case we don't want it to be null or have some '' default value but we would add that for the migrations to work (I guess your ALTER command adds the body_html COLUMN with null value too, until we call the save method for all the posts). What I have done to be able to run ./manage evolve is: 1. make body_html nullable (so it could be added with the null value to the past Posts) 2. run the evolve command 3. change the models.py file back (remove nullable attributes) to be able to update from you in the future without potential conflicts The problem now is that I wont be able to evolve something else in the future because django-evolution will detect that my Post models are changed since my last evolve (and it will not be willing to evolve Posts.body_html the way they are now) and will not run my other model migration either. In the current state I won't be able to use django-evolution to evolve django-forum and will have to run commands from your README.txt, which is not so bad but is kind of rudimentary (especially considering that I have the django-evolution system installed and tracking my changes). I can still run the evolve command specifying my other application names to avoid django-forum. In conclusion it is not so bad but it's a little annoying. I don't want body_html to be null but I am using django-evolution (alternative to south or dmigrations). This is why I did not write the ALTER commands described in your README.txt. In this case we don't want it to be null or have some '' default value but we would add that for the migrations to work (I guess your ALTER command adds the body_html COLUMN with null value too, until we call the save method for all the posts). What I have done to be able to run ./manage evolve is: 1. make body_html nullable (so it could be added with the null value to the past Posts) 2. run the evolve command 3. change the models.py file back (remove nullable attributes) to be able to update from you in the future without potential conflicts The problem now is that I wont be able to evolve something else in the future because django-evolution will detect that my Post models are changed since my last evolve (and it will not be willing to evolve Posts.body_html the way they are now) and will not run my other model migration either. In the current state I won't be able to use django-evolution to evolve django-forum and will have to run commands from your README.txt, which is not so bad but is kind of rudimentary (especially considering that I have the django-evolution system installed and tracking my changes). I can still run the evolve command specifying my other application names to avoid django-forum. In conclusion it is not so bad but it's a little annoying. Sep 02, 2009 issue 42 (Not compatible with setuptools) commented on by rwpoulton - I don't have checkin access right now but will do this when I get home tonight. I should have done it long ago, sorry. I don't have checkin access right now but will do this when I get home tonight. I should have done it long ago, sorry. Sep 02, 2009 issue 78 (A little change to ThreadPostDetails) reported by bymenda - I added a better format for the ThreadPostDetails, did a change to the template and corrected a css error. The djangoForumThreadPostContainer div is for something I'm planning to do in a few days. Greetings, Rafa Muñoz Cárdenas I added a better format for the ThreadPostDetails, did a change to the template and corrected a css error. The djangoForumThreadPostContainer div is for something I'm planning to do in a few days. Greetings, Rafa Muñoz Cárdenas Sep 02, 2009 issue 77 (Don't do anything if nobody subscribed the thread) reported by bymenda - If nobody is subscribed to the thread then don't do all that work for nothing :) Greeting, Rafa Muñoz Cárdenas If nobody is subscribed to the thread then don't do all that work for nothing :) Greeting, Rafa Muñoz Cárdenas Sep 02, 2009 issue 76 (Changing New thread's position) reported by bymenda - I know most people won't use the default templates but I think it's a necessary change. In my humble oppinion it's too easy for the user to create a new thread. So easy that it could be confused with sending a reply post if you have many tabs opened in your browser with different thread lists or whatsoever. In terms of usability it adds more excise (effort to do something) when creating a new thread, but on the other hand it's completely necessary as well because it's a more serious task compared to sending a simple post. We rarely create threads in every forum we enter, so it doesn't make sense to render the same form so many times if we are only going to use it a few occasions. Greetings, Rafa Muñoz Cárdenas. I know most people won't use the default templates but I think it's a necessary change. In my humble oppinion it's too easy for the user to create a new thread. So easy that it could be confused with sending a reply post if you have many tabs opened in your browser with different thread lists or whatsoever. In terms of usability it adds more excise (effort to do something) when creating a new thread, but on the other hand it's completely necessary as well because it's a more serious task compared to sending a simple post. We rarely create threads in every forum we enter, so it doesn't make sense to render the same form so many times if we are only going to use it a few occasions. Greetings, Rafa Muñoz Cárdenas. Sep 02, 2009 issue 75 (Evolving forums) commented on by bymenda - But why do you want the body_html to be null? Any message cannot be null, so either the body_html. Did you run the commands detailed in the new README.txt? But why do you want the body_html to be null? Any message cannot be null, so either the body_html. Did you run the commands detailed in the new README.txt? Sep 01, 2009 issue 42 (Not compatible with setuptools) commented on by xphuture - I would like to know if a decision will be made soon for this issue. Or maybe we can make a 1.0-alpha branch with this issue, the current other one, and the releasing a 1.0. I would like to know if a decision will be made soon for this issue. Or maybe we can make a 1.0-alpha branch with this issue, the current other one, and the releasing a 1.0. Aug 31, 2009 issue 75 (Evolving forums) reported by fericean - What steps will reproduce the problem? 1. Deploy a forum before adding body_html 2. Update the forum 3. Try to evolve it The body_html cannot be evolved because it does not have a default value and it cannot be null. I made it nullable and after that I resaved all the posts (it were only a few at this time). Is there another way to do it? What steps will reproduce the problem? 1. Deploy a forum before adding body_html 2. Update the forum 3. Try to evolve it The body_html cannot be evolved because it does not have a default value and it cannot be null. I made it nullable and after that I resaved all the posts (it were only a few at this time). Is there another way to do it? Aug 27, 2009 issue 52 (Forum order_id field (feature request)) Status changed by rwpoulton - Added in SVN r52. Thanks! Existing users will need to update their database as mentioned above (and in the README file) Status: Fixed Added in SVN r52. Thanks! Existing users will need to update their database as mentioned above (and in the README file) Status: Fixed Aug 27, 2009 issue 73 (Changes for real-time markup) changed by rwpoulton - Added in SVN r52. Thanks! Existing users will need to update their database as mentioned above (and in the README file) Status: Fixed Owner: rwpoulton Labels: Type-Enhancement −Type-Defect Added in SVN r52. Thanks! Existing users will need to update their database as mentioned above (and in the README file) Status: Fixed Owner: rwpoulton Labels: Type-Enhancement −Type-Defect Aug 27, 2009 r52 (Two enhancements: Issue #52: Add forum ordering, thanks to m...) committed by rwpoulton - Two enhancements: Issue #52 : Add forum ordering, thanks to macmichael01. Issue #73 : Call markdown when saving rather than when rendering text, thanks to bymenda. Two enhancements: Issue #52 : Add forum ordering, thanks to macmichael01. Issue #73 : Call markdown when saving rather than when rendering text, thanks to bymenda. Aug 27, 2009 issue 72 ("Go back to thread" proposal) changed by rwpoulton - Added in SVN r51. Thank you for the patch. Status: Fixed Owner: rwpoulton Added in SVN r51. Thank you for the patch. Status: Fixed Owner: rwpoulton Aug 27, 2009 r51 (Issue #72: Add a 'Go back to thread' link when subscribing t...) committed by rwpoulton - Issue #72 : Add a 'Go back to thread' link when subscribing to threads. Thanks to 'bymenda' for the patch. Issue #72 : Add a 'Go back to thread' link when subscribing to threads. Thanks to 'bymenda' for the patch. Aug 26, 2009 issue 72 ("Go back to thread" proposal) commented on by bymenda - Woah, I don't know what could happen xD Woah, I don't know what could happen xD Aug 26, 2009 issue 72 ("Go back to thread" proposal) commented on by rwpoulton - I like the sound of your idea, however can you please re-submit these patches as they appear to be 0-byte size. I like the sound of your idea, however can you please re-submit these patches as they appear to be 0-byte size. Aug 24, 2009 issue 71 (Models fail to validate under Django 1.1) Status changed by rwpoulton - This has already been fixed. Status: Duplicate This has already been fixed. Status: Duplicate Aug 24, 2009 issue 74 (If a forum has multiple groups assigned to it managers.Forum...) changed by rwpoulton - Fixed in SVN r50. Thanks! Status: Fixed Owner: rwpoulton Fixed in SVN r50. Thanks! Status: Fixed Owner: rwpoulton Aug 24, 2009 r50 (Fix issue #74 - if a forum can be accessed by multiple grou...) committed by rwpoulton - Fix issue #74 - if a forum can be accessed by multiple groups, and a user is in those multiple groups, forums were being listed twice. Thanks to Jamie Curle for the patch Fix issue #74 - if a forum can be accessed by multiple groups, and a user is in those multiple groups, forums were being listed twice. Thanks to Jamie Curle for the patch Aug 12, 2009 issue 74 (If a forum has multiple groups assigned to it managers.Forum...) commented on by jamie.cu...@designcc.co.uk - Thanks! Patch Attached. Thanks! Patch Attached. Aug 12, 2009 issue 74 (If a forum has multiple groups assigned to it managers.Forum...) commented on by bymenda - Hi! To submit a patch it's just: $ diff -Naur old_file new_file > file.patch That's it! Hi! To submit a patch it's just: $ diff -Naur old_file new_file > file.patch That's it! Aug 10, 2009 issue 74 (If a forum has multiple groups assigned to it managers.Forum...) commented on by jamie.cu...@designcc.co.uk - I'm also new to testing, but I've attached a zip containing some fixtures and some rudimentary tests that catch this error. I'm also new to testing, but I've attached a zip containing some fixtures and some rudimentary tests that catch this error.

issue 75 (Evolving forums) commented on by fericean - I don't want body_html to be null but I am using django-evolution (alternative to south or dmigrations). This is why I did not write the ALTER commands described in your README.txt. In this case we don't want it to be null or have some '' default value but we would add that for the migrations to work (I guess your ALTER command adds the body_html COLUMN with null value too, until we call the save method for all the posts). What I have done to be able to run ./manage evolve is: 1. make body_html nullable (so it could be added with the null value to the past Posts) 2. run the evolve command 3. change the models.py file back (remove nullable attributes) to be able to update from you in the future without potential conflicts The problem now is that I wont be able to evolve something else in the future because django-evolution will detect that my Post models are changed since my last evolve (and it will not be willing to evolve Posts.body_html the way they are now) and will not run my other model migration either. In the current state I won't be able to use django-evolution to evolve django-forum and will have to run commands from your README.txt, which is not so bad but is kind of rudimentary (especially considering that I have the django-evolution system installed and tracking my changes). I can still run the evolve command specifying my other application names to avoid django-forum. In conclusion it is not so bad but it's a little annoying.

I don't want body_html to be null but I am using django-evolution (alternative to south or dmigrations). This is why I did not write the ALTER commands described in your README.txt. In this case we don't want it to be null or have some '' default value but we would add that for the migrations to work (I guess your ALTER command adds the body_html COLUMN with null value too, until we call the save method for all the posts). What I have done to be able to run ./manage evolve is: 1. make body_html nullable (so it could be added with the null value to the past Posts) 2. run the evolve command 3. change the models.py file back (remove nullable attributes) to be able to update from you in the future without potential conflicts The problem now is that I wont be able to evolve something else in the future because django-evolution will detect that my Post models are changed since my last evolve (and it will not be willing to evolve Posts.body_html the way they are now) and will not run my other model migration either. In the current state I won't be able to use django-evolution to evolve django-forum and will have to run commands from your README.txt, which is not so bad but is kind of rudimentary (especially considering that I have the django-evolution system installed and tracking my changes). I can still run the evolve command specifying my other application names to avoid django-forum. In conclusion it is not so bad but it's a little annoying.

Last 7 days

Last 30 days

Earlier this year