Talk:IntraACL

Subpages (4) →

creating a template that allows edit right only to the creator of the page

is it possible with this extension ? if yes how ?

Thanks,

Nicolas

VitaliyFilippov (talk) 22:56, 1 September 2016 (MSK) No if you mean "IntraACL right template". MediaWiki template based on some parser function... maybe if you have a parser function that prints the creator of a given page.

Uninstallation instructions

Hi, I'm missing instructions how to remove the extension after it has been set up according to this page. Krichter (talk) 21:54, 31 August 2014 (MSK)

VitaliyFilippov (talk) 22:54, 1 September 2016 (MSK) Revert patch, remove LocalSettings part.

Malfunctions

Mediawiki : 1.23.4 IntraACL : 2.1.6

Case 1 Combine mode : OVERRIDE

Rules applied via IntraACL

• ACL on the namespace without read or edit permission for the user
• ACL on the category of the page without read or edit permission for the user
• No ACL on the page
• But ACL on the parent category of the page's category with read permission for the user

In this case, the page is visible for the user when he accesses by the direct link or through search page. Therefore, I was obliged to prohibit the use of hierarchical categories. If the user, on the parent category clicks the category without read or edit permission for him, he was forbidden.

Case 2 Combine mode : SHRINK

Rules applied via IntraACL

• ACL on the namespace with read permission for the user
• ACL on the first category of the page without read or edit permission for the user
• ACL on the second category of the page with read permission for the user
• No ACL on the page

In this case, the page is visible for the user. Therefore, I was obliged to prohibit the use of multiples categories for a page.

In SHRINK mode, is-it possible to test all the categories Security Descriptor and if just one category deny the access, the user is forbidden.

Thanks you very much for this extention.

Best Regards

VitaliyFilippov (talk) 22:54, 1 September 2016 (MSK) All page categories and their parents are always treated equally, regardless of SHRINK or OVERRIDE modes. Parent category ACLs do not override subcategory ACLs, and category permissions never intersect with each other. This is by design and may be tricky to fix.

Requires HTTP Server Name Header

Hi, I've found that IntraACL doesn't work unless your web server sets the HTTP server name header. The ACL tab is missing, and the access controls aren't applied, but the Special:IntraACL page still appears.

I don't consider this to be a bug, but I think it would be helpful if there was a note about this somewhere in the documentation for other people who encounter the same problem.

MediaWiki 1.27.1 Support

Does this extension support MW 1.27.1? I see the patch for 1.26 but when I ran it against my 1.27.1 installation it broke some things.

I reverted the Includes folder with the files from my install/upgrade file to get back up and running.

VitaliyFilippov (talk) 22:50, 1 September 2016 (MSK) Not yet, it needs a rebased patch for 1.27.

When Will Updated Patch Be Available?

Hello - do you have an estimate of when a patch for 1.27.1 will be available? I'd like to update my 1.26.4 installation to 1.27.1 due to some VisualEditor enhancements but having Intra ACL working is essential. Thanks! Ben.Hinc (talk) 00:09, 1 October 2016 (MSK)

Hi - Same here... Please let us know. Thanks. Titi18 (talk) 16:28, 10 October 2016 (MSK)

Hiding a link to a protected page

Hi, is it possible to avoid showing a link to a protected page instead of redirect to "Permission Denied" page? Thanks, Gabriele.

Can's create User:.... pages. Can create Talk:.... pages.

When MediaWiki4intranet's clean installer config adds an administrator e.g. WikiSysop it grants default rights found in DefaultSettings.php.(listed bottom) and/or BaseSettings.php.

For some reason I can create Talk Pages but I can't create User Pages for any user. I always get You don't have permission to access /..../index.php/User:'......' on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. Which is not correct as the Namespace User has the following IntraACL.

{{#access: assigned to = Group/Administrator, actions = *, manage}} {{#manageRights: assigned to = User:WikiSysop}}

The Administrator Group has {{#addMember: members = User:WikiSysop}} {{#manageRights: assigned to = User:WikiSysop}}

WikiSysop is Member of: Bureaucrats, Semantic MediaWiki administrators and Administrators & Implicit member of: Autoconfirmed users.

Happens even if $wgGroupPermissions['*']['edit'] = true; $wgGroupPermissions['*']['view'] = true; $wgGroupPermissions['*']['createpage'] = true;

Any suggestions?

Permission Error with Special:CreateProperty

Special:CreateProperty results in a white page. No php errors show.

runJobs adds Special:CreateClass properties just fine. AS it disables IntraACL to do this I suspect I have a permission error. php maintenance/runJobs.php

• • WARNING: IntraACL security checks are disabled because
  • $_SERVER[SERVER_NAME] is empty, which probably means we are in console

Any suggestions?

— (anonymous) • 11 December 2013 at 22:37 (GMT) last edited on 26 May 2019 at 21:38

[ List view ]Replies

(no items)

Please login to comment.