[wikka-community] Page Groups in Wikka?
th yelton
thyml
Fri Nov 9 17:22:36 GMT 2007
Hi Brian, Thanks for responding. Comments/response inserted below.
Preface: I am deep in the process of trying to find a wiki (or other
collaborative/CMS software) for my church's website. I like Wikka very
much along with your community and am hoping to end my search (which has
already gone on far too long for my liking) here. But there are certain
requirements which Wikka may not meet "out of the box" or even with
published mods. One of those is ACLs on page groups. Another may be
the upload problem, i.e. allowing users to do uploads safely, (but I
haven't delved into that much yet.)
Brian Koontz wrote:
> On Thu, Nov 08, 2007 at 12:18:44PM -0500, th yelton wrote:
>
>> I'm not sure if it is sufficient, in fact it might cause problems. You
>> see one problem that we have is that most of our users and potential
>> users are technically naive, some are even technically averse. I am
>> concerned that this kind of "ACL inheritance at page creation" may be a
>> bit too subtle and confusing for them.
>>
>
> Since I wrote this bit of code, I feel compelled to respond :) You
> can configure this setting in wikka.config.php to take on the ACLs of
> the page you're cloning from. It should *always* be safe to default
> this to "yes" (unless you change the default perms to some very
> restrictive perms, and still have less restrictive pages on the
> system).
>
The default for my system *will* be as you say more restrictive (only
registered users can view/edit/comment) but there will be pages that can
be viewed by everyone.
If I implemented the access-time permission inheritance mechanism I am
proposing I would probably want to turn off all the "inheritance at
creation" mechanisms. I would want the default page ACLs to be "", i.e.
blank, nil, so that the page would inherit its permissions from the
system defaults at access-time from the system defaults or its "parent"
page.
It is unclear to me whether creation-time inheritance is planned to
become part of core Wikka. If so will it be possible to turn off all
creation-time inheritance in the config file?
Comment on creation-time inheritance: It seems to me that this is an
attempt to work around the lack of some sort of hierarchy in Wikka -- a
not entirely satisfactory workaround. When I clone a page it probably
for reasons that have nothing to do with ACLs -- more likely it is
because it has some cool structure, form, table, whatever that I want to
use as a template. So then I have to set the ACLs manually anyhow. If
I (as an ordinary user) don't understand my organization's particular
needs for privacy, security, etc. then I am likely to do it wrong. So
then (I as admin) have to get involved (which I-admin doesn't wants to
do ;-)
I predict that, sooner or later, you guys are going to have to "bite
the bullet" and implement some kind of page hierarchy in core Wikka.
Not just for ACLs but for scalability and usability. I applaud your
resistance so far -- I don't love hierarchies either but there comes a
point where they are indispensable.
>
>> I don't see why a database change would be necessary. To tell if a user
>> can access BoardMinutes the code would first look at the ACLs of
>> BoardMinutes. If the the needed ACL was blank in BoardMinutes then look
>> at the ACL of Board. If Board is blank or nonexistent then I suppose
>> you could use the configuration default. Everything needed is already
>> in the database.
>>
>
> Given the flat hierarchy of pages, there are currently no fields
> in the DB to link one page to another. This would require a DB
> change, and would by default introduce a hierarchical structure.
> This has been debated quite frequently, and at this point, the "flat
> structure" arguments have won out over the "hierarchical structure"
> arguments.
>
I have not made my intent clear. The inheritance I'm talking about is
based purely on the page name. BoardMinutes inherits ACLs from Board
not because of any link between them in the database, but only because
"BoardMinutes" begins with "Board". This can be determined at the time
of the access attempt by parsing the actual page names into their
WikiWord components.
An improvement on this basic proposal would be to add a new allowable
character to page names ("." or "/") and use that to divide the page
name instead of WikiWord boundaries, e.g. "Board.Minutes.June" or
"Board/Minutes/June" instead of "BoardMinutesJune". The advantage is
that it is more explicit and doesn't conflict with the descriptive
quality of WikiWords.
>
>> I am reluctant to make code mods if the Wikka developers think this is a
>> really bad idea. I think that would be a recipe for trouble down the
>> line. So what do you think?
>>
>
> I don't think anyone believes this to be a "bad" idea. It's simply
> the Wikka philosophy to keep things lightweight, fast, and secure.
> Introducing a hierarchy of pages simply doesn't fit with this
> philosophy.
>
I am very glad to hear it and agree wholeheartedly with the Wikka
philosophy. But I disagree with the last statement. I think what I am
proposing (or something similar) would in fact be "lightweight, fast and
secure". At least I don't see why not.
Internally the namespace is still flat with my proposal. The difference
is mostly in the minds of the users.
> That said, I don't believe it would be too much trouble to create a
> hierarchy of pages. However, it's not trivial: I just wrapped up
> threaded comments, and it was quite a bit of work to ensure the
> traversal routines were not only fast but robust as well. Things to
> think about: Can pages have multiple parents? Can parents have
> multiple children? What happens to the children of a child that's
> deleted? What happens if a child is deleted, and the perms of *its*
> child are different from its grandparent? (If the orphaned page were
> then to adopt the perms of its grandparent, and those perms were less
> restrictive, you might have problems...)
>
Good questions, easily answered:
* Pages cannot have multiple parents. One or None. Also one or no
grandparent, one or no great grandparent, etc.
* Pages can have multiple children.
* When a parent is deleted ACLs are inherited from the
great-grandparent, great-great-grandparent, etc. up to the system
defaults. Which is exactly what I would want/expect.
* Nothing happens to the children of a child that is deleted except
that their effective access permissions may change. But this
happens automatically without any database changes since
permissions are determined at access time.
* If a child page has its own ACLs set then it doesn't matter what
happens to its parent, grandparent, etc. It doesn't inherit ACLs
unless its own are blank. Parent ACLs never override child ACLs.
(It could easily be the other way around, parent ACLs always
override child ACLs, but that is not what I am currently proposing).
> I'm not saying it can't be done, but it would require some non-trivial
> level of design and coding effort.
>
> --Brian
I think it may be less than you think -- I'm still hoping for trivial
effort, actually ;-) But I await with breath bated all attempts to
deflate this trial balloon.
- Thomas
--
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.wikkawiki.org/pipermail/community_wikkawiki.org/attachments/20071109/18d4fbae/attachment.html
More information about the community
mailing list