You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jspwiki.apache.org by Bob Paige <bo...@gmail.com> on 2008/12/03 18:56:19 UTC
permissions question
Up til now we have one JSPWiki in-house for use by development. But now we
are finding that some of the assumptions made by engineering need to be
documented for customer service (CS) and the trainers. These assumptions are
being documented in the dev wiki, but we are looking for the best way to
make them available to CS and I'd like opinions.
Optimally, I restrict which pages the CS people can see by some rule. Since
I am planning on a single "CustomerService" page as the entry-point for CS
people, fashioning a rule that only allowed them to see pages that link to
the "CustomerService" page would be good.
Option 1: send 'em a link
The simplest thing to do would be to show them where the wiki is and have at
it. As long as they don't login, they can't change anything.
The downside to this approach is that CS may stumble upon dev-oriented wiki
pages which could lead to more questions ("what does this mean?") or,
worst-case, CS tells the customer something based on their (potentially
flawed) intrepetation of what they find there.
Option 2: assign permissions on each page
This page (http://www.jspwiki.org/wiki/PermissionTag) says you can only
specify edit permissions, and what I would want is the ability to indicate
which pages the CS person could view
Downsides:
- doesn't seem to provide what I need
- would require adding the permission to every page I want excluded
Option 3: write a filter
I could write a filter that does what I described above; if the page doesn't
link to the "CustomerService" page, don't let them see it.
Downside:
- gotta write the filter (not too hard)
- if we want the CS people to add pages in the future, how well would this
work?
Option 4: separate wiki
I could easily create a separate wiki for the CS people.
Downside: dev people would have to switch to the other wiki to create the
pages for it, which goes against my whole motivation in doing this.
Thoughts?
--
Bobman
RE: permissions question
Posted by "Hobbs, Joseph" <Jo...@53.com>.
I have a similar scenario as well. I have a team using a Wiki to
document their Operational data (private to team), but would also like
to use wiki's to distribute information out to the rest of the company
(public to internal users). The other issue is that Operations Data and
'Documentation' are intermingled, so searching can be an issue when
you're looking for document on X, but instead get a listing of everyone
referencing X.
My current solution was to break things up in 3 separate wiki's. I have
an Operations, Documentation, and Public wiki. They're side by side and
I've configured Inter-Wiki links to allow people to easily link between
them. The Public wiki is readable by any internal user, whereas
Documentation and Operations are limited only to team members. This
allow us to segment data appropriately, and gives us an easy means of
publishing data internally as well.
To take things a step further, I also have Roles configured for
Authenticated, Author, and Admin. Authenticated can read, Authors can
create/modify, and Admins can do the rest. You also have Wiki ACL's to
give you page by page control where necessary.
Not the best solution, but it's working so far. It takes a bit more
planning and some content cleanup, but in the end I think it will make
things much easier to deal with content wise.
As far as permissions tag, are you referring to the [{ALLOW <something>
<someone>}] tag? I use this today to prevent Authenticated or Author
users from modifying Wiki 'structure' pages such as TitleBox or
LeftMenu. These pages are restricted to edit by Admin, but are viewable
by anyone. I use a combination of:
[{ALLOW edit Admin}]
[{ALLOW view All}]
This grants edit to Admin, but allows anyone to view the content. Don't
forget the 'view ALL' though, or only Admins will be able to edit and
view. The downfall to this solution is that existing pages not for
public consumption need to be modified to limit access. New 'dev' pages
would also have to be tagged, or they'd be visible as well.
Joseph Hobbs
Lead Technology Architect
Enabling Technologies : Technical Services
Fifth Third Bank
Phone : (513) 534-5908
Fax : (513) 534-3408
Email : Joseph.Hobbs@53.com
-----Original Message-----
From: Bob Paige [mailto:bobpaige@gmail.com]
Sent: Wednesday, December 03, 2008 12:56 PM
To: jspwiki-user@incubator.apache.org
Subject: permissions question
Up til now we have one JSPWiki in-house for use by development. But now
we
are finding that some of the assumptions made by engineering need to be
documented for customer service (CS) and the trainers. These assumptions
are
being documented in the dev wiki, but we are looking for the best way to
make them available to CS and I'd like opinions.
Optimally, I restrict which pages the CS people can see by some rule.
Since
I am planning on a single "CustomerService" page as the entry-point for
CS
people, fashioning a rule that only allowed them to see pages that link
to
the "CustomerService" page would be good.
Option 1: send 'em a link
The simplest thing to do would be to show them where the wiki is and
have at
it. As long as they don't login, they can't change anything.
The downside to this approach is that CS may stumble upon dev-oriented
wiki
pages which could lead to more questions ("what does this mean?") or,
worst-case, CS tells the customer something based on their (potentially
flawed) intrepetation of what they find there.
Option 2: assign permissions on each page
This page (http://www.jspwiki.org/wiki/PermissionTag) says you can only
specify edit permissions, and what I would want is the ability to
indicate
which pages the CS person could view
Downsides:
- doesn't seem to provide what I need
- would require adding the permission to every page I want excluded
Option 3: write a filter
I could write a filter that does what I described above; if the page
doesn't
link to the "CustomerService" page, don't let them see it.
Downside:
- gotta write the filter (not too hard)
- if we want the CS people to add pages in the future, how well would
this
work?
Option 4: separate wiki
I could easily create a separate wiki for the CS people.
Downside: dev people would have to switch to the other wiki to create
the
pages for it, which goes against my whole motivation in doing this.
Thoughts?
--
Bobman
This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated.
Re: permissions question
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
Whee! Thanks :-)
/Janne
On Dec 4, 2008, at 16:23 , Hobbs, Joseph wrote:
> Not anymore. I just dug through this the other day, so I had the data
> handy :-)
>
> Joseph Hobbs
> Lead Technology Architect
> Enabling Technologies : Technical Services
> Fifth Third Bank
> Phone : (513) 534-5908
> Fax : (513) 534-3408
> Email : Joseph.Hobbs@53.com
>
> -----Original Message-----
> From: Bob Paige [mailto:bobpaige@gmail.com]
> Sent: Thursday, December 04, 2008 9:07 AM
> To: jspwiki-user@incubator.apache.org
> Subject: Re: permissions question
>
> Janne,
>
> Thanks for the links. BTW, that last one (WikiPermissions) is blank :)
>
> --
> Bobman
>
> On Wed, Dec 3, 2008 at 2:11 PM, Janne Jalkanen
> <Ja...@ecyrd.com>wrote:
>
>>
>> Unfortunately the page at http://www.jspwiki.org/wiki/PermissionTag
>>
>> is woefully out of date. Please see
>>
>> http://doc.jspwiki.org/2.8/wiki/Security
>> http://doc.jspwiki.org/2.8/wiki/PagePermissions
>> http://doc.jspwiki.org/2.8/wiki/WikiPermissions
>>
>> (We would need someone to really go through all pages and figure out
> what
>> is obsolete and what is not - we moved documentation to
> doc.jspwiki.orgquite a while ago, but loads of old pages still
> remain.)
>>
>> /Janne
>>
>>
>> On Dec 3, 2008, at 19:56 , Bob Paige wrote:
>>
>> Up til now we have one JSPWiki in-house for use by development. But
> now we
>>> are finding that some of the assumptions made by engineering need to
> be
>>> documented for customer service (CS) and the trainers. These
> assumptions
>>> are
>>> being documented in the dev wiki, but we are looking for the best
>>> way
> to
>>> make them available to CS and I'd like opinions.
>>>
>>> Optimally, I restrict which pages the CS people can see by some
>>> rule.
>>> Since
>>> I am planning on a single "CustomerService" page as the entry-point
> for CS
>>> people, fashioning a rule that only allowed them to see pages that
> link to
>>> the "CustomerService" page would be good.
>>>
>>> Option 1: send 'em a link
>>> The simplest thing to do would be to show them where the wiki is and
> have
>>> at
>>> it. As long as they don't login, they can't change anything.
>>>
>>> The downside to this approach is that CS may stumble upon
> dev-oriented
>>> wiki
>>> pages which could lead to more questions ("what does this mean?")
>>> or,
>>> worst-case, CS tells the customer something based on their
> (potentially
>>> flawed) intrepetation of what they find there.
>>>
>>> Option 2: assign permissions on each page
>>> This page (http://www.jspwiki.org/wiki/PermissionTag) says you can
> only
>>> specify edit permissions, and what I would want is the ability to
> indicate
>>> which pages the CS person could view
>>>
>>> Downsides:
>>> - doesn't seem to provide what I need
>>> - would require adding the permission to every page I want excluded
>>>
>>> Option 3: write a filter
>>> I could write a filter that does what I described above; if the page
>>> doesn't
>>> link to the "CustomerService" page, don't let them see it.
>>>
>>> Downside:
>>> - gotta write the filter (not too hard)
>>> - if we want the CS people to add pages in the future, how well
>>> would
> this
>>> work?
>>>
>>> Option 4: separate wiki
>>> I could easily create a separate wiki for the CS people.
>>>
>>> Downside: dev people would have to switch to the other wiki to
>>> create
> the
>>> pages for it, which goes against my whole motivation in doing this.
>>>
>>> Thoughts?
>>>
>>> --
>>> Bobman
>>>
>>
>>
>
> This e-mail transmission contains information that is confidential
> and may be privileged. It is intended only for the addressee(s)
> named above. If you receive this e-mail in error, please do not
> read, copy or disseminate it in any manner. If you are not the
> intended recipient, any disclosure, copying, distribution or use of
> the contents of this information is prohibited. Please reply to the
> message immediately by informing the sender that the message was
> misdirected. After replying, please erase it from your computer
> system. Your assistance in correcting this error is ap
RE: permissions question
Posted by "Hobbs, Joseph" <Jo...@53.com>.
Not anymore. I just dug through this the other day, so I had the data
handy :-)
Joseph Hobbs
Lead Technology Architect
Enabling Technologies : Technical Services
Fifth Third Bank
Phone : (513) 534-5908
Fax : (513) 534-3408
Email : Joseph.Hobbs@53.com
-----Original Message-----
From: Bob Paige [mailto:bobpaige@gmail.com]
Sent: Thursday, December 04, 2008 9:07 AM
To: jspwiki-user@incubator.apache.org
Subject: Re: permissions question
Janne,
Thanks for the links. BTW, that last one (WikiPermissions) is blank :)
--
Bobman
On Wed, Dec 3, 2008 at 2:11 PM, Janne Jalkanen
<Ja...@ecyrd.com>wrote:
>
> Unfortunately the page at http://www.jspwiki.org/wiki/PermissionTag
>
> is woefully out of date. Please see
>
> http://doc.jspwiki.org/2.8/wiki/Security
> http://doc.jspwiki.org/2.8/wiki/PagePermissions
> http://doc.jspwiki.org/2.8/wiki/WikiPermissions
>
> (We would need someone to really go through all pages and figure out
what
> is obsolete and what is not - we moved documentation to
doc.jspwiki.orgquite a while ago, but loads of old pages still remain.)
>
> /Janne
>
>
> On Dec 3, 2008, at 19:56 , Bob Paige wrote:
>
> Up til now we have one JSPWiki in-house for use by development. But
now we
>> are finding that some of the assumptions made by engineering need to
be
>> documented for customer service (CS) and the trainers. These
assumptions
>> are
>> being documented in the dev wiki, but we are looking for the best way
to
>> make them available to CS and I'd like opinions.
>>
>> Optimally, I restrict which pages the CS people can see by some rule.
>> Since
>> I am planning on a single "CustomerService" page as the entry-point
for CS
>> people, fashioning a rule that only allowed them to see pages that
link to
>> the "CustomerService" page would be good.
>>
>> Option 1: send 'em a link
>> The simplest thing to do would be to show them where the wiki is and
have
>> at
>> it. As long as they don't login, they can't change anything.
>>
>> The downside to this approach is that CS may stumble upon
dev-oriented
>> wiki
>> pages which could lead to more questions ("what does this mean?") or,
>> worst-case, CS tells the customer something based on their
(potentially
>> flawed) intrepetation of what they find there.
>>
>> Option 2: assign permissions on each page
>> This page (http://www.jspwiki.org/wiki/PermissionTag) says you can
only
>> specify edit permissions, and what I would want is the ability to
indicate
>> which pages the CS person could view
>>
>> Downsides:
>> - doesn't seem to provide what I need
>> - would require adding the permission to every page I want excluded
>>
>> Option 3: write a filter
>> I could write a filter that does what I described above; if the page
>> doesn't
>> link to the "CustomerService" page, don't let them see it.
>>
>> Downside:
>> - gotta write the filter (not too hard)
>> - if we want the CS people to add pages in the future, how well would
this
>> work?
>>
>> Option 4: separate wiki
>> I could easily create a separate wiki for the CS people.
>>
>> Downside: dev people would have to switch to the other wiki to create
the
>> pages for it, which goes against my whole motivation in doing this.
>>
>> Thoughts?
>>
>> --
>> Bobman
>>
>
>
This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated.
Re: permissions question
Posted by Bob Paige <bo...@gmail.com>.
Janne,
Thanks for the links. BTW, that last one (WikiPermissions) is blank :)
--
Bobman
On Wed, Dec 3, 2008 at 2:11 PM, Janne Jalkanen <Ja...@ecyrd.com>wrote:
>
> Unfortunately the page at http://www.jspwiki.org/wiki/PermissionTag
>
> is woefully out of date. Please see
>
> http://doc.jspwiki.org/2.8/wiki/Security
> http://doc.jspwiki.org/2.8/wiki/PagePermissions
> http://doc.jspwiki.org/2.8/wiki/WikiPermissions
>
> (We would need someone to really go through all pages and figure out what
> is obsolete and what is not - we moved documentation to doc.jspwiki.orgquite a while ago, but loads of old pages still remain.)
>
> /Janne
>
>
> On Dec 3, 2008, at 19:56 , Bob Paige wrote:
>
> Up til now we have one JSPWiki in-house for use by development. But now we
>> are finding that some of the assumptions made by engineering need to be
>> documented for customer service (CS) and the trainers. These assumptions
>> are
>> being documented in the dev wiki, but we are looking for the best way to
>> make them available to CS and I'd like opinions.
>>
>> Optimally, I restrict which pages the CS people can see by some rule.
>> Since
>> I am planning on a single "CustomerService" page as the entry-point for CS
>> people, fashioning a rule that only allowed them to see pages that link to
>> the "CustomerService" page would be good.
>>
>> Option 1: send 'em a link
>> The simplest thing to do would be to show them where the wiki is and have
>> at
>> it. As long as they don't login, they can't change anything.
>>
>> The downside to this approach is that CS may stumble upon dev-oriented
>> wiki
>> pages which could lead to more questions ("what does this mean?") or,
>> worst-case, CS tells the customer something based on their (potentially
>> flawed) intrepetation of what they find there.
>>
>> Option 2: assign permissions on each page
>> This page (http://www.jspwiki.org/wiki/PermissionTag) says you can only
>> specify edit permissions, and what I would want is the ability to indicate
>> which pages the CS person could view
>>
>> Downsides:
>> - doesn't seem to provide what I need
>> - would require adding the permission to every page I want excluded
>>
>> Option 3: write a filter
>> I could write a filter that does what I described above; if the page
>> doesn't
>> link to the "CustomerService" page, don't let them see it.
>>
>> Downside:
>> - gotta write the filter (not too hard)
>> - if we want the CS people to add pages in the future, how well would this
>> work?
>>
>> Option 4: separate wiki
>> I could easily create a separate wiki for the CS people.
>>
>> Downside: dev people would have to switch to the other wiki to create the
>> pages for it, which goes against my whole motivation in doing this.
>>
>> Thoughts?
>>
>> --
>> Bobman
>>
>
>
Re: permissions question
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
Unfortunately the page at http://www.jspwiki.org/wiki/PermissionTag
is woefully out of date. Please see
http://doc.jspwiki.org/2.8/wiki/Security
http://doc.jspwiki.org/2.8/wiki/PagePermissions
http://doc.jspwiki.org/2.8/wiki/WikiPermissions
(We would need someone to really go through all pages and figure out
what is obsolete and what is not - we moved documentation to
doc.jspwiki.org quite a while ago, but loads of old pages still remain.)
/Janne
On Dec 3, 2008, at 19:56 , Bob Paige wrote:
> Up til now we have one JSPWiki in-house for use by development. But
> now we
> are finding that some of the assumptions made by engineering need
> to be
> documented for customer service (CS) and the trainers. These
> assumptions are
> being documented in the dev wiki, but we are looking for the best
> way to
> make them available to CS and I'd like opinions.
>
> Optimally, I restrict which pages the CS people can see by some
> rule. Since
> I am planning on a single "CustomerService" page as the entry-point
> for CS
> people, fashioning a rule that only allowed them to see pages that
> link to
> the "CustomerService" page would be good.
>
> Option 1: send 'em a link
> The simplest thing to do would be to show them where the wiki is
> and have at
> it. As long as they don't login, they can't change anything.
>
> The downside to this approach is that CS may stumble upon dev-
> oriented wiki
> pages which could lead to more questions ("what does this mean?") or,
> worst-case, CS tells the customer something based on their
> (potentially
> flawed) intrepetation of what they find there.
>
> Option 2: assign permissions on each page
> This page (http://www.jspwiki.org/wiki/PermissionTag) says you can
> only
> specify edit permissions, and what I would want is the ability to
> indicate
> which pages the CS person could view
>
> Downsides:
> - doesn't seem to provide what I need
> - would require adding the permission to every page I want excluded
>
> Option 3: write a filter
> I could write a filter that does what I described above; if the
> page doesn't
> link to the "CustomerService" page, don't let them see it.
>
> Downside:
> - gotta write the filter (not too hard)
> - if we want the CS people to add pages in the future, how well
> would this
> work?
>
> Option 4: separate wiki
> I could easily create a separate wiki for the CS people.
>
> Downside: dev people would have to switch to the other wiki to
> create the
> pages for it, which goes against my whole motivation in doing this.
>
> Thoughts?
>
> --
> Bobman