Add a help desk or knowledge base to your Django project with only a few lines of boilerplate code.

Hi there,

I'm a researcher studying software evolution. As part of my current research, I'm studying the implications of open-sourcing a proprietary software, for instance, if the project succeed in attracting newcomers. However, I observed that some projects, like django-knowledge, deleted the software history during the transition to open-source.

Knowing that software history is indispensable for developers (e.g., developers need to refer to history several times a day), I would like to ask django-knowledge developers the following four brief questions:

1. Why did you decide to not keep the software history?
2. Do the core developers faced any kind of problems, when trying to refer to the old history? If so, how did they solve these problems?
3. Do the newcomers faced any kind of problems, when trying to refer to the old history? If so, how did they solve these problems?
4. How does the lack of history impacted on software evolution? Does it placed any burden in understanding and evolving the software?

Thanks in advance for your collaboration,

Gustavo Pinto, PhD http://www.gustavopinto.org

/knowledge url is working fine, but then when clicking a question, below is returned

" NoReverseMatch at /knowledge/ask/ Reverse for 'knowledge_thread' with arguments '(3, u'')' and keyword arguments '{}' not found. 1 pattern(s) tried: ['knowledge/questions/(?P<question_id>\d+)/(?P[a-z0-9-_]+)/$']"

And in the error message it refers to " knowledge/templates/django_knowledge/sidebar.html, error at line 11" which is "" and official djangoproject.com says "exception NoReverseMatch The NoReverseMatch exception is raised by django.core.urlresolvers when a matching URL in your URLconf cannot be identified based on the parameters supplied"

django-knowledge documentation ( http://django-knowledge.readthedocs.org/en/latest/customize.html#if-you-have-your-own-template-shim-wrapper ) mentions a KNOWLEDGE_BASE_TEMPLATE setting that does not exist in source code.

This patch allow user to customize base template. KNOWLEDGE_BASE_TEMPLATE's default is django_knowledge/base.html .

inner.html template now extends BASE_TEMPLATE template variable, which is passed in views. I considered to pass this variable to the template using a context processor, but it has several drawbacks like asking user to append it in his configuration file.

Our system is still using django v1.3.1 so we need the older version of django-knowledge v0.0.6. Would it be possible to add the older versions of django-knowledge to the pip registry?

Thanks and have an epic day!

First and last names of users were treated as non-unicode strings. This lead the application to stop working (decode error) if a user with non-ascii name saved a question. I added two characters to fix this problem - declaring strings as unicode were the user lastname/firstname are read.

PS: Sorry for two separate commits - its the first time I use github ;-) PPS: Thank you for your work. I really like it.

Hello again !

Here's a little fix to address the issue you mentioned about BASE_TEMPLATE variable passing.

If the template argument is forgotten, it defaults to bundled base template.

The migrations relied on auth.user. Added a couple of lines to knowledge.utils to lookup the custom user model. Ported/patched the migrations to use the new lookup variable so that they handle being run when there is only a custom user model.

Previous urls.py priority will cause question page not accessible, but category page instead, when SLUG_URLS is set to False.

I use Chinese, so slug is almost useless, so I turn it off.

This adds a configuration file for Travis CI and fixes a number of issues with testing that came up. I think the repo owner still needs to link their account to Travis and click on a few buttons to fully enable Travis.

I've also removed the version pinning from requirements.txt - it made testing multiple versions of Django impossible without downloading it twice (once for the version pinned in requirements.txt and then once again for the version specified in the testing matrix)

Hello Zapier,

I'm a pretty new developer, I'm currently building a point of sale system for my company that i've built with django. I wanted to also integrate a knowledge base for all of the processes that we've written. This project had the nuts and bolts of what I wanted so I installed it into my project and updated everything to get it working. While doing that I thought I'd contribute to my first ever project on github. I know that you guys don't maintain this anymore so I'm not sure if you guys will see this but it's worth a shot. Any feedback would be great and I apologize for any commit messages that aren't very clear. You can tell that I work alone most of the time.

The get_query_set method has been renamed to get_queryset in Django 1.6 https://docs.djangoproject.com/en/1.8/releases/1.6/#get-query-set-and-similar-methods-renamed-to-get-queryset and is removed in Django 1.8 https://docs.djangoproject.com/en/1.8/releases/1.8/#features-removed-in-1-8

Traceback:
File "/home/user/my-env/local/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response
  132.                     response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/home/user/my-env/local/lib/python2.7/site-packages/knowledge/views.py" in knowledge_index
  45.     questions = Question.objects.can_view(request.user)\
File "/home/user/my-env/local/lib/python2.7/site-packages/knowledge/managers.py" in can_view
  10.         qs = super(QuestionManager, self).get_query_set()\

Exception Type: AttributeError at /knowledge/
Exception Value: 'super' object has no attribute 'get_query_set'

Categories were left out from the form to submit a new question, meaning that the only way to assign a question to a category was through the admin interface. ModelForm creates the same kind of interface that's in admin for assigning categories when given the categories field; so I added it for authenticated users and made it optional.

Django 1.6 removes markup from the django.core feature set.

More information:

django.contrib.markup will be removed following an accelerated deprecation.

The solution is one of two things:

1. (Not recommended, but useful as a patch) Use django-markup-deprecated. This allows you to keep the {% load markup %} template tag.
2. (Recommended) Use django-markupfield where relevant in your models.

In my (currently unmerged) fork and commit of this project I added support for Textile. I am also going to fix this problem using the second approach above and commit to my fork.