Hi, Matt, Something similar I have in one of the projects (besides LDAP yet). My solution was as following: - XEM - You logically spread your information to the following structure: Main Wiki -> Workspaces (or sub-wikis) -> Spaces - All Users are Global Users - Each sub-wiki has its own policy access rights based on groups. In multi-project it's essential to plan good structure and acces rights policy. It took us nearly a month to describe desired logic and access rights policies for all projects. :-)))) In my case there are: main wiki and 30+ subwikis, 80+ users for now. All of them are private, no registration available. So, It's better understand workflow logic and customize data structure accordingly. Most probably it won't be as simple as you described it: only three departments' -workspaces. If you need completely paranoic privacy for some projects, better use separate server, separate XWiki instance to keep secrets in. :-)) As for links: wiki-wiki. If you have ONE wiki engine - it's quite easy: wiki:Space.PageName. Bad news: - there is no WYSIWYG interface to manage this, that makes it a bit more complicated for non-advanced users. - Wiki-wiki links are not updated on page rename. See http://jira.xwiki.org/browse/XWIKI-8346 Kind Regards, Dmitry Птн 30 Ноя 2012 11:59:25 от Flatfender <[email protected]>:
Ok, thank you for that, the subspace thing is good to know. How I
would set this up is now starting to puzzle me.
So let's say I have 3 departments
Engineering
Hardware
Software
All three will collaborate on the same projects and may need access to
the same wiki content, but all may also want private pages that are
department specific. So I guess if I didn't a separate wiki
department, they could use interwiki links to reference project pages.
This would probably necessitate some people from each department
being in the other departments wiki group. But then if they created a
private namespace, the people from the other department could see it.
I could combat this by creating two wikigroups for each department,
like wiki_engineering_public, and wiki_engineering_private. Then only
departmental members would be in the private group and namespaces
could be in the private group to protect.
Or I guess everything is public, and then group perms on the namespace
to protect?
The problem is that we're a pretty small company 250 people and most
of the people are cross department/project functional.
I'll look more at the perms side of things.
Thank you.
On Fri, Nov 30, 2012 at 11:23 AM, Thomas Mortagne
<[email protected]> wrote:
On Fri, Nov 30, 2012 at 4:29 PM, Flatfender <[email protected]> wrote:
All,
I'm thinking of deploying xwiki either community or commercial. I've
looked through the docs, and searched the forum as well.
Here is my question. Can I create groups in AD/LDAP and tie them to
Namespaces to get protected wiki's by department?
We have some departments that are ok with an Open wiki, but others
like accounting want restricted access. I'd like to manage this at
the AD/LDAP group level instead of the xwiki application level, is
that possible?
Is namespaces the right way to go to achieve departmental wiki's or
would I have to look at multiple wiki's in a wiki farm?
You can link LDAP groups to XWiki groups and then you can setup your rights
on XWiki based on theses groups like restricting the access to a
space/wikis only to a specific XWiki group. This is usually the way we work
with LDAP.
The main difference between spaces and wikis is that, since XWiki does not
support subspaces, all the pages will be at the same level for a
department. Appart from this it depends how different you want your
spaces/wikis to be or if you want to have different domain name for each
department like admin.myhost.com etc. Note that you can apply completely
different skins at space level.
Thanks,
Matt P.
_______________________________________________
users mailing list
--
Thomas Mortagne
_______________________________________________
users mailing list
_______________________________________________
users mailing list
Kind regards, Dmitry