[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