View Issue Details

IDProjectCategoryView StatusLast Update
0000061WackoWikiactionpublic2009-10-13 16:05
ReporterEoNy Assigned ToTann San  
PriorityhighSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
Product Version4.2 
Fixed in Version5.0.beta 
Summary0000061: New subpages should use parent ACL
Description25-01-2006 19:39 tomspilman:

I have several client accessible private clusters/subpages on our wiki. In these cases i create a subpage under the projects page for a client like so:

Projects/ClientProject

I then usually create an alias for all the clients that need read/write access to that cluster.

So far it works well except in the case where the client needs to create a new subpage under that cluster. In that case, even though the client has write access to that cluster, he is denied access to create a new page.

The problem is that since the page doesn't exist it returns the default ACL for the site which in our case happens to be restricted to one of our employee alias.

What we wanted to see happen was that when creating a new subpage, it returns the ACL for the parent page.
Additional InformationSo i went ahead and fixed the code myself. In wacko.php in LoadACL change:

if (!$acl && $useDefaults)
{
// First look for parent ACL, so that clusters/subpages
// work correctly.
if ( strstr($tag, "/") )
{
$parent = preg_replace( "/^(.*)\\/([^\\/]+)$/", "$1", $tag );

// By letting it fetch defaults, it will automatically recurse
// up the tree of parent pages... fetching the ACL on the root
// page if necessary.
$acl = $this->LoadAcl( $parent, $privilege, 1 );
}

// If we still don't have an acl then use the site defaults.
if (!$acl)
{
$acl = array("supertag" => $supertag, "page_tag" => $tag,
"privilege" => $privilege,
"list" => $this->GetConfigValue("default_".$privilege."_acl"),
"time" => date("YmdHis"),
"default" => "1" );
}
}

This seems to work fine and doesn't impact site performance.
TagsNo tags attached.

Activities

Tann San

2009-04-10 14:38

manager   ~0000637

Implemented what was written in previous comment.

Issue History

Date Modified Username Field Change
2007-08-31 16:20 EoNy New Issue
2007-08-31 16:20 EoNy Legacy => NEW
2007-08-31 21:02 administrator Legacy NEW => NPJ
2008-05-16 02:46 administrator Description Updated
2008-05-16 03:01 administrator Status new => feedback
2009-04-10 14:38 Tann San Status feedback => assigned
2009-04-10 14:38 Tann San Assigned To => Tann San
2009-04-10 14:38 Tann San Note Added: 0000637
2009-04-10 14:38 Tann San Status assigned => resolved
2009-04-10 14:38 Tann San Fixed in Version => 5.0.0
2009-04-10 14:38 Tann San Resolution open => fixed
2009-10-13 16:05 administrator Fixed in Version 5.0.0 => 5.0.beta
2010-03-08 10:09 administrator Category Action => action