Hi,
I noticed the SVN tables.sql now has a permissions table. Dare I dream that per page permissioning is on the way? Is the ethos of the wikipedia changing, or has some money been thrown into the development? Is it likely to be in 1.10, or a few versions away?
Best regards,
Alex
On 12/02/07, Alex Powell alexp@exscien.com wrote:
I noticed the SVN tables.sql now has a permissions table. Dare I dream that per page permissioning is on the way? Is the ethos of the wikipedia changing, or has some money been thrown into the development? Is it likely to be in 1.10, or a few versions away?
No, we've just split off page editing permissions (for protection) into a new table, and introduced a few columns in advance, to facilitate future features such as expiring protection. This was done at the same time as cascading protection was introduced.
I am not aware of plans to introduce per-page access permissions to the software beyond anything we already have, at this time. MediaWiki is a wiki engine, not a content management system.
Rob Church
Rob Church schreef:
On 12/02/07, Alex Powell alexp@exscien.com wrote:
I noticed the SVN tables.sql now has a permissions table. Dare I dream that per page permissioning is on the way? Is the ethos of the wikipedia changing, or has some money been thrown into the development? Is it likely to be in 1.10, or a few versions away?
No, we've just split off page editing permissions (for protection) into a new table, and introduced a few columns in advance, to facilitate future features such as expiring protection. This was done at the same time as cascading protection was introduced.
I am not aware of plans to introduce per-page access permissions to the software beyond anything we already have, at this time. MediaWiki is a wiki engine, not a content management system.
Rob Church
Hoi, MediaWiki is a versatile tool. Gartner wrote at some stage: "Knowledge management became affordable thanks to the MediaWiki boys". The point being, yes it is a wiki engine at its core, it is however used in many settings. There have been several requests for per-page access permissions. There have been implementations of this. They just did not make it into the MediaWiki SVN. This is a shame because as a consequence you have a fork. Forking is really unproductive. With some regularity the same issue raises its ugly head again; often resulting in a new fork. Thanks, GerardM
On 2/12/07, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, MediaWiki is a versatile tool. Gartner wrote at some stage: "Knowledge management became affordable thanks to the MediaWiki boys". The point being, yes it is a wiki engine at its core, it is however used in many settings. There have been several requests for per-page access permissions. There have been implementations of this. They just did not make it into the MediaWiki SVN. This is a shame because as a consequence you have a fork. Forking is really unproductive. With some regularity the same issue raises its ugly head again; often resulting in a new fork. Thanks, GerardM
If someone was able to implement this as an extension, without modifying core code, then they might have a better chance of making it into SVN. However given that it's something that devs have previously said they aren't planning to include, and given that it's not likely to be something the Wikimedia projects will ever need, it may not get included. But at least if it's an extension then it can be independently maintained without the problems of forking.
Hoi, MediaWiki is a versatile tool. Gartner wrote at some stage: "Knowledge management became affordable thanks to the MediaWiki boys". The point being, yes it is a wiki engine at its core, it is however used in many settings. There have been several requests for per-page access permissions. There have been implementations of this. They just did not make it into the MediaWiki SVN. This is a shame because as a consequence you have a fork. Forking is really unproductive. With some regularity the same issue raises its ugly head again; often resulting in a new fork. Thanks, GerardM
If someone was able to implement this as an extension, without modifying core code, then they might have a better chance of making it into SVN.
If such a thing existed, under a suitable license (etc etc), as an _extension_ only, then I for one would be happy to check it in to SVN.
Others may then decide to delete it (probably on the grounds that "it was against user freedoms") ... and no doubt the irony inherent in restricting what was in MediaWiki's extension SVN, so as to "increase freedoms" would be completely lost of such people. Interventionist nanny-state fascists! :-)
Part of freedom is the freedom to decide for yourself what you want to happen on your systems. For example, Linux lets me encrypt my private personal data so that others cannot access it. Is this "against user freedoms"? If not, why should wikis be different?
Brion has strongly implied that in the past. That's what WONTFIX means: not that we aren't willing to code it, but that we aren't even willing to accept it. But it's his decision, of course.
An unequivocal answer to this would be good, because it's a recurring question which isn't going away.
Brion, would you refuse to allow a patch for per-page ACLs on political (rather than technical) reasons? I.e. if the code was clean, it was off by default, it had little or no overhead if you weren't using it, most of it was in an extension, with only limited changes to the core where required, the license was acceptable, it was used at a number of sites, it fulfilled a user need / desire, there didn't seem to be any security problems, the patch's developers were communicate and responsive, it used the same coding style as other code, was well-commented and documented, etc etc - Would you revert such a patch: Yes or No?
All the best, Nick.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Nick Jenkins wrote:
Brion, would you refuse to allow a patch for per-page ACLs on political (rather than technical) reasons? I.e. if the code was clean, it was off by default, it had little or no overhead if you weren't using it, most of it was in an extension, with only limited changes to the core where required, the license was acceptable, it was used at a number of sites, it fulfilled a user need / desire, there didn't seem to be any security problems, the patch's developers were communicate and responsive, it used the same coding style as other code, was well-commented and documented, etc etc
- Would you revert such a patch: Yes or No?
Such a patch is not very likely to exist, as it's an inherently sticky problem because it *has* to pervade the system in order to work.
If an attempt to do it appeared out of nowhere, I would have to assume it doesn't work properly and would indeed revert it; why waste everyone's time plonking in a big ugly system that probably won't even work properly?
As an example see the code related to use of rev_deleted; it has little tendrils everywhere and still isn't ready to go live after being in for some time.
While there may be a possibility that we'll end up with that on a page basis, it's not going to be pretty.
So no, I would not accept such a "patch". Ongoing work to move in that direction, _maybe_ _possibly_. But some big honkin "patch" would be inherently useless crap.
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
.... a patch for per-page ACLs ....
- Would you revert such a patch: Yes or No?
[...snip...]
So no, I would not accept such a "patch". Ongoing work to move in that direction, _maybe_ _possibly_. But some big honkin "patch" would be inherently useless crap.
Fair enough, and good answer!
So, if you want such a thing, use as-small-as-possible incremental updates, with lots of visibility and prior announcement and opportunity for review, and don't introduce dead code / functionality that isn't being used. Plus the other standard stuff listed before (clean code, etc etc) - i.e. don't give any technical reason to say no.
And remember, nobody said it would be easy! ;-)
All the best, Nick.
On 12/02/07, Gerard Meijssen gerard.meijssen@gmail.com wrote:
being, yes it is a wiki engine at its core, it is however used in many settings. There have been several requests for per-page access permissions. There have been implementations of this. They just did not make it into the MediaWiki SVN. This is a shame because as a consequence you have a fork. Forking is really unproductive. With some regularity
To implement a secure read permissions system, you would need to rewrite a considerable number of code points, because the system was "designed", if it was designed at all, with absolutely no concern over who has access to the data. Users can export it, transclude it, view histories, etc. So far, we haven't seen a single, clean implementation of this.
I'm not saying it's *never ever ever* going to happen - I used to, but it's inevitable that Wikimedia is going to drop the "freedom" attitude soon enough. What I *am* saying is that, as far as I know, there's still nothing on the roadmap for us to go back and start that process, and so far, it's been resisted.
If a corporate environment wishes to adapt software to its needs, and if it insists upon bastardising that software to act outside of its scope, then it is welcome do - you can do whatever the hell you like with MediaWiki, provided you stick to the terms of the licence agreement. What you can't do is force us to make changes that are fundamentally opposed to the overall direction of the progress.
Rob Church
"Rob Church" robchur@gmail.com wrote in message news:e92136380702120735q642054c7g336b4844900391f3@mail.gmail.com...
On 12/02/07, Gerard Meijssen
gerard.meijssen@gmail.com wrote:
being, yes it is a wiki engine at its core, it is however used in many settings. There have been several requests for per-page access permissions. There have been implementations of this. They just did not make it into the MediaWiki SVN. This is a shame because as a consequence you have a fork. Forking is really unproductive. With some regularity
[SNIP]
If a corporate environment wishes to adapt software to its needs, and if it insists upon bastardising that software to act outside of its scope, then it is welcome do - you can do whatever the hell you like with MediaWiki, provided you stick to the terms of the licence agreement. What you can't do is force us to make changes that are fundamentally opposed to the overall direction of the progress.
So, out of interest, are you saying that even if somebody implemented this cleanly and completely and provided a fully tested patch against HEAD, it would still not be accepted to the main development branch?
- Mark Clements (HappyDog)
On 12/02/07, Mark Clements gmane@kennel17.co.uk wrote:
So, out of interest, are you saying that even if somebody implemented this cleanly and completely and provided a fully tested patch against HEAD, it would still not be accepted to the main development branch?
That would be the decision of the lead developer.
Rob Church
<snip>
. What you can't do is force us to make changes that are
fundamentally opposed to the overall direction of the progress.
Rob Church
Just pointing out the possible change of direction of progress...
Possibly this change has been checked in error - it was from a branch. Still it begs the question: has the position on this changed, as this change is there meaning that the code would need to be reviewed to put in page protection. This really is the last thing that needs to go into the trunk. Extending MW to do pretty much anything other than protection is now possible through hooks, and the extensions can be relatively non invasive. However, as often mentioned, for security reasons extensions cannot add this completely. Trunk changes are needed. This looks like a step in that (right) direction.
As a side note what is img_auth.php for? I cannot see where it is used. Seems to be a potential access control mechanism into the image repository...
Alex Powell wrote:
As a side note what is img_auth.php for? I cannot see where it is used. Seems to be a potential access control mechanism into the image repository...
It allows setting permissions to images (images, not image pages). Extends the read permission to images. It is not /used/: you'd need to install it (see its header).
On Mon, Feb 12, 2007 at 03:35:51PM +0000, Rob Church wrote:
I'm not saying it's *never ever ever* going to happen - I used to, but it's inevitable that Wikimedia is going to drop the "freedom" attitude soon enough. What I *am* saying is that, as far as I know, there's still nothing on the roadmap for us to go back and start that process, and so far, it's been resisted.
Freedom for whom to do what? :-)
Cheers, -- jra
On 2/12/07, Gerard Meijssen gerard.meijssen@gmail.com wrote:
There have been several requests for per-page access permissions. There have been implementations of this. They just did not make it into the MediaWiki SVN. This is a shame because as a consequence you have a fork. Forking is really unproductive. With some regularity the same issue raises its ugly head again; often resulting in a new fork.
I'm not aware of any forks. I'm aware of a large-scale patch that aims to implement this, that I think is kept up to date with the stable releases.
On 2/12/07, Mark Clements gmane@kennel17.co.uk wrote:
So, out of interest, are you saying that even if somebody implemented this cleanly and completely and provided a fully tested patch against HEAD, it would still not be accepted to the main development branch?
Brion has strongly implied that in the past. That's what WONTFIX means: not that we aren't willing to code it, but that we aren't even willing to accept it. But it's his decision, of course.
On 2/12/07, Alex Powell alexp@exscien.com wrote:
Possibly this change has been checked in error - it was from a branch. Still it begs the question: has the position on this changed, as this change is there meaning that the code would need to be reviewed to put in page protection. This really is the last thing that needs to go into the trunk.
I'm not clear on what you mean here. The page_restrictions table was just a restructuring of the schema. Without having looked at the actual code, I assume that pr_type can only be 'edit' or 'move', just as has always been true. I think it's been possible for a long time to add other stuff to a global like $wgRestrictionTypes, but I'm not aware of whether that actually works, and doubt that whether it works or not has been changed by the existence of a new table.
So I'm guessing that in the field:
-- The protection type (edit, move, etc) pr_type varchar(255) NOT NULL,
pr_type = "read" will not be supported/undefined because "its a wiki" (whatever that means)? Seems like a bad way to go, and actually the time limiting factor on reads could be useful as contentious pages could be restricted for a period of time, whilst people work out what to do with them qv potentially libelous comments...
On 2/12/07, Rob Church robchur@gmail.com wrote:
On 12/02/07, Alex Powell alexp@exscien.com wrote:
I noticed the SVN tables.sql now has a permissions table. Dare I dream
that
per page permissioning is on the way? Is the ethos of the wikipedia changing, or has some money been thrown into the development? Is it
likely
to be in 1.10, or a few versions away?
No, we've just split off page editing permissions (for protection) into a new table, and introduced a few columns in advance, to facilitate future features such as expiring protection. This was done at the same time as cascading protection was introduced.
I am not aware of plans to introduce per-page access permissions to the software beyond anything we already have, at this time. MediaWiki is a wiki engine, not a content management system.
Rob Church
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Alex Powell wrote:
I noticed the SVN tables.sql now has a permissions table. Dare I dream that per page permissioning is on the way? Is the ethos of the wikipedia changing, or has some money been thrown into the development? Is it likely to be in 1.10, or a few versions away?
We have always had per-page permissions; they have simply been branched to another table to allow for more flexible manipulations and interactions.
Keep in mind that there is no support for per-page *read* permissions, though, and none is planned.
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
wikitech-l@lists.wikimedia.org