Support for multiple wikis
mjacksonw opened this issue · 7 comments
Title says pretty much all of it. It would be amazing to be able to have multiple wikis on one site, with each Article owned by/associated with a higher level Wiki object.
The wiki is hierarchical, so you have to explain exactly what properties this wiki should have that's not possible through the article/urlpath system :)
It's not a won't do, it's just something that was (hopefully) thought through before :)
It's (perhaps highly) likely that I'm just not seeing how to do these things given the early state of documentation and such, which is totally understandable, but I'd like to:
- Have separate hierarchies that have no visible relationship to each other.
- Have articles with the same "name" in separate namespaces -- one "wiki" cannot link to another.
- Have independent permission structures for each -- wiki A's groups are distinct from wiki B's, and the "other" for each one is separate as well: "other" users of wiki A cannot read/write to wiki B.
- An overarching "admin" group that does indeed get to work across wikis would be ideal as well, but this could just be handled by adding these users to the respective admin groups of each wiki.
If those things can be done under the existing structure, that's even better. Just not clear on how to make that happen at the moment.
Generally: Since the wiki relies on django.contrib.auth for users and groups, you cannot have two groups with the same name, but different members. This will only cause you the possibility of clashes, even though there is a notion of separate wiki entities.
I can see the point about the links, but maybe that's more about not being able to link to something that an editor does not have read access to. Actually, this is already a feature of wiki.plugins.links -- it only suggests articles that the user has read permissions to!
Have separate hierarchies that have no visible relationship to each other.
This is a definition case. Even if a Wiki model is established, and the Article model is given a ForeignKey to the WIki model, there is no definite way to answer the question: Can a wiki refer to another wiki?
An overarching "admin" group that does indeed get to work across wikis would be ideal as well, but this could just be handled by adding these users to the respective admin groups of each wiki.
You can implement your own functions for handling permissions. The default permission is to look for the moderate, grant and assign permission groups, which are global.
If a bit late, I hope it's inspiring enough to look for solutions on the existing foundation.
Another tip:
If you are using the wiki with other apps, you can still create the illusion of having the wiki for different hierarchies by adding it as the very last handler in your urlconf. In that way, if you have some app handling stuff in the "/path/some-app/" url hierarchy, you could still fill in dummy articles with slugs "path", "some-app" and "wiki", and you would get a wiki located at "/path/some-site/wiki/".
However, the link plugin would then create link tags formatted as [Title](/path/some-site/wiki/Title) - but that's still about fixing the links plugin to support relative paths or simply article ids.
Regarding this topic, we develop a django-based social platform with multiple apps allowing members to showcase their project, and participate in working groups and we want to have one wiki per group (which would be located at http://myplateform.org/group/group-name/wiki/). In order to avoid having to create dummy pages, is it possible, with the existing structure, to set one root-page per group (like http://myplateform.org/group/group-name/wiki/my-group-root-page) and then be able to extend the hierarchy from this point? If more advanced customization is needed, where would you advice to start with?
I think you should stick to the one-tree thought a bit... at the moment, separating the project into several wiki trees is not an immediate feature to be implemented.
However, you can achieve the same by having a redirect setup for instance:
group-name/wiki/ -> wiki/group-name/
And then ensure that you have set the correct permissions on the group-name subtree.
If you pursued the "separate tree" model, you wouldn't be able to cross-reference content and links between the wikis. So I think since you're talking about a social platform with working groups, consider the benefit of having those groups able to reference each others work.
I know it's been a while since this subject has been approached - I actually do want distinct wikis with a foreignKey relationship for each wiki to a given parent object which might be a client-facing wiki or an internal project wiki or a public information wiki
I understand that these could exist in the same tree with the above workaround but it doesn't fully address the request for my use case.