How do I restrict MediaWiki user groups from access to portions of my wiki by namespace?How to add URL's to...
How to have a sharp product image?
Is Diceware more secure than a long passphrase?
What was Apollo 13's "Little Jolt" after MECO?
Why do games have consumables?
How long after the last departure shall the airport stay open for an emergency return?
A Note on N!
Can a stored procedure reference the database in which it is stored?
Should the Product Owner dictate what info the UI needs to display?
What is the term for a person whose job is to place products on shelves in stores?
What *exactly* is electrical current, voltage, and resistance?
A strange hotel
Why must Chinese maps be obfuscated?
Magical attacks and overcoming damage resistance
Find the identical rows in a matrix
Drawing a german abacus as in the books of Adam Ries
What to do with someone that cheated their way through university and a PhD program?
Older movie/show about humans on derelict alien warship which refuels by passing through a star
Is there metaphorical meaning of "aus der Haft entlassen"?
Multiple options vs single option UI
Co-worker works way more than he should
What does a straight horizontal line above a few notes, after a changed tempo mean?
Is Electric Central Heating worth it if using Solar Panels?
Why did C use the -> operator instead of reusing the . operator?
Is there a word for the censored part of a video?
How do I restrict MediaWiki user groups from access to portions of my wiki by namespace?
How to add URL's to wiki (MediaWiki) powered documentation?Is it possible to mirror a MediaWiki article from another wiki?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
In the release notes of Mediawiki 1.18 there is this line:
$wgGroupPermissions now supports per namespace permissions.
I cannot find the implementation within the documentation. The wiki page for $wgGroupPermissions has not yet been updated to handle this change.
I wish to put copyrighted material up that will only be accessible to a certain class of users while leaving the rest of the wiki open.
mediawiki
add a comment |
In the release notes of Mediawiki 1.18 there is this line:
$wgGroupPermissions now supports per namespace permissions.
I cannot find the implementation within the documentation. The wiki page for $wgGroupPermissions has not yet been updated to handle this change.
I wish to put copyrighted material up that will only be accessible to a certain class of users while leaving the rest of the wiki open.
mediawiki
add a comment |
In the release notes of Mediawiki 1.18 there is this line:
$wgGroupPermissions now supports per namespace permissions.
I cannot find the implementation within the documentation. The wiki page for $wgGroupPermissions has not yet been updated to handle this change.
I wish to put copyrighted material up that will only be accessible to a certain class of users while leaving the rest of the wiki open.
mediawiki
In the release notes of Mediawiki 1.18 there is this line:
$wgGroupPermissions now supports per namespace permissions.
I cannot find the implementation within the documentation. The wiki page for $wgGroupPermissions has not yet been updated to handle this change.
I wish to put copyrighted material up that will only be accessible to a certain class of users while leaving the rest of the wiki open.
mediawiki
mediawiki
edited 25 mins ago
Michael Hampton♦
176k27321651
176k27321651
asked Jan 26 '12 at 22:11
EFHEFH
1133
1133
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
I'm having a very hard time parsing what exactly occurred here (wikimedia's infamous bureaucracy).. but what it looks like to me is that the release note made it in (diff), but the change to actually enable the feature was reverted.
The only clear notes on this seem to be in the commit notes for the revert, with nothing in the outstanding bug.
Reverted r92364 (per-namespace permissions).
This is the wrong configuration format for such a feature, and the wrong interface. We already have certain per-namespace permissions in the Title class, and we didn't need to add extra formal parameters to a whole lot of User methods in order to get them. The feature should be implemented wholly in Title, and the concept of user rights should remain relatively simple and easy to understand, and independent of its many applications, i.e. a user either has a right or doesn't. Rights are just a tool for developing access policies; the complexity should be in the caller.
Well, chalk up several wasted hours of upgrade time for naught. I'll stop looking and holding my breath then and start looking into this Title class. The big reason I pushed up to 1.18 was to be able to close off one namespace. Oh well.
– EFH
Jan 26 '12 at 23:09
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "2"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f354081%2fhow-do-i-restrict-mediawiki-user-groups-from-access-to-portions-of-my-wiki-by-na%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I'm having a very hard time parsing what exactly occurred here (wikimedia's infamous bureaucracy).. but what it looks like to me is that the release note made it in (diff), but the change to actually enable the feature was reverted.
The only clear notes on this seem to be in the commit notes for the revert, with nothing in the outstanding bug.
Reverted r92364 (per-namespace permissions).
This is the wrong configuration format for such a feature, and the wrong interface. We already have certain per-namespace permissions in the Title class, and we didn't need to add extra formal parameters to a whole lot of User methods in order to get them. The feature should be implemented wholly in Title, and the concept of user rights should remain relatively simple and easy to understand, and independent of its many applications, i.e. a user either has a right or doesn't. Rights are just a tool for developing access policies; the complexity should be in the caller.
Well, chalk up several wasted hours of upgrade time for naught. I'll stop looking and holding my breath then and start looking into this Title class. The big reason I pushed up to 1.18 was to be able to close off one namespace. Oh well.
– EFH
Jan 26 '12 at 23:09
add a comment |
I'm having a very hard time parsing what exactly occurred here (wikimedia's infamous bureaucracy).. but what it looks like to me is that the release note made it in (diff), but the change to actually enable the feature was reverted.
The only clear notes on this seem to be in the commit notes for the revert, with nothing in the outstanding bug.
Reverted r92364 (per-namespace permissions).
This is the wrong configuration format for such a feature, and the wrong interface. We already have certain per-namespace permissions in the Title class, and we didn't need to add extra formal parameters to a whole lot of User methods in order to get them. The feature should be implemented wholly in Title, and the concept of user rights should remain relatively simple and easy to understand, and independent of its many applications, i.e. a user either has a right or doesn't. Rights are just a tool for developing access policies; the complexity should be in the caller.
Well, chalk up several wasted hours of upgrade time for naught. I'll stop looking and holding my breath then and start looking into this Title class. The big reason I pushed up to 1.18 was to be able to close off one namespace. Oh well.
– EFH
Jan 26 '12 at 23:09
add a comment |
I'm having a very hard time parsing what exactly occurred here (wikimedia's infamous bureaucracy).. but what it looks like to me is that the release note made it in (diff), but the change to actually enable the feature was reverted.
The only clear notes on this seem to be in the commit notes for the revert, with nothing in the outstanding bug.
Reverted r92364 (per-namespace permissions).
This is the wrong configuration format for such a feature, and the wrong interface. We already have certain per-namespace permissions in the Title class, and we didn't need to add extra formal parameters to a whole lot of User methods in order to get them. The feature should be implemented wholly in Title, and the concept of user rights should remain relatively simple and easy to understand, and independent of its many applications, i.e. a user either has a right or doesn't. Rights are just a tool for developing access policies; the complexity should be in the caller.
I'm having a very hard time parsing what exactly occurred here (wikimedia's infamous bureaucracy).. but what it looks like to me is that the release note made it in (diff), but the change to actually enable the feature was reverted.
The only clear notes on this seem to be in the commit notes for the revert, with nothing in the outstanding bug.
Reverted r92364 (per-namespace permissions).
This is the wrong configuration format for such a feature, and the wrong interface. We already have certain per-namespace permissions in the Title class, and we didn't need to add extra formal parameters to a whole lot of User methods in order to get them. The feature should be implemented wholly in Title, and the concept of user rights should remain relatively simple and easy to understand, and independent of its many applications, i.e. a user either has a right or doesn't. Rights are just a tool for developing access policies; the complexity should be in the caller.
answered Jan 26 '12 at 22:58
Shane Madden♦Shane Madden
104k9147224
104k9147224
Well, chalk up several wasted hours of upgrade time for naught. I'll stop looking and holding my breath then and start looking into this Title class. The big reason I pushed up to 1.18 was to be able to close off one namespace. Oh well.
– EFH
Jan 26 '12 at 23:09
add a comment |
Well, chalk up several wasted hours of upgrade time for naught. I'll stop looking and holding my breath then and start looking into this Title class. The big reason I pushed up to 1.18 was to be able to close off one namespace. Oh well.
– EFH
Jan 26 '12 at 23:09
Well, chalk up several wasted hours of upgrade time for naught. I'll stop looking and holding my breath then and start looking into this Title class. The big reason I pushed up to 1.18 was to be able to close off one namespace. Oh well.
– EFH
Jan 26 '12 at 23:09
Well, chalk up several wasted hours of upgrade time for naught. I'll stop looking and holding my breath then and start looking into this Title class. The big reason I pushed up to 1.18 was to be able to close off one namespace. Oh well.
– EFH
Jan 26 '12 at 23:09
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f354081%2fhow-do-i-restrict-mediawiki-user-groups-from-access-to-portions-of-my-wiki-by-na%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown