https://bugzilla.wikimedia.org/show_bug.cgi?id=13953
--- Comment #25 from Krinkle <[email protected]> --- (In reply to comment #16) > (In reply to comment #15) > > If your wiki uses a shared user table, or any other non-CA global > authentication configuration (LDAP possibly), then it's entirely re-usable. > I'm > not aware of what in core that offers this feature, nor any other extensions > (excluding Skizzerz's extension mentioned above). > > > I think we should either reject this feature, or add it to CentralAuth. > > Rejecting this feature isn't an option ;) > What I meant is, if this is small enough that it doesn't need an extension (e.g. can be done with LocalSettings), then we'd reject it as a feature in CentralAuth, but just document how to enable it using mediawiki core features in your LocalSettings. (In reply to comment #17) > (In reply to comment #15) > > I think this feature is small enough and sufficiently linked to CentralAuth > > that it doesn't make sense to split out. > > Sufficiently linked in what ways? It needs a pointer to the 'central' wiki and a way to resolve that reference in the site matrix. I thought this was CentralAuth feature. Though SiteMatrix is indeed a CentralAuth feature, it looks like wgLocalDatabases and (Multi)-SiteConfiguration are actually core features, so it isn't really linked to CentralAuth in any way other than the ability to verify that the user's account is confirmed on both wikis. That's the only thing the patch had that is CentralAuth specific. If we move this else where, we should still somehow enforce that (perhaps through a hook that CentralAuth can use to communicate with this other extension, when one has both installed). (In reply to comment #21) > It's not a matter of whether it's problematic, per se, it's a matter of > whether it's expected behavior. As I laid out in comment 14 [..] > into the CentralAuth extension probably defies reasonable user expectations. (In reply to comment #14) > (In reply to comment #13) > It's a matter of expectations: > > 1) Would you expect anyone to want to install a GlobalBits script but not > install CentralAuth? > > 2) Would you expect when installing CentralAuth that it would include the > ability to have global bits? > > After framing it this way, I think I see your point. A separate extension > probably makes sense. Pick an extension name? :-) Though I mind it being in a separate extension, I'm pretty sure the question to both questions is "Yes, but..". 1) Yes, though perhaps not just CentralAuth. As pointed out, there are other ways to set up wiki farms. But each one probably comes with small details that need to be handled specifically to make it work correctly. For example, in the case of CentralAuth we need the global user module to take into account that the user has a local account on both wikis involved. Even if we move this to a separate extension, we still need something in CentralAuth that will tab into this other extension to enforce that. And given that the amount of code to create global user modules is so small, I figured it wouldn't be worth it. We might as well document that bit code, advocate its use and implement it in CentralAuth as primary example + the CentralAuth specific bits, and then people using other ways to set up wiki farms can copy the same example and implement their bits as well. Again, I'm fine with it being an extension, but it will still need some local settings tuning, and hooks with CentralAuth. (In reply to comment #20) > (In reply to comment #19) > > I agree with Krinkle, I think this module is small enough that it can live > > in > > CentralAuth without a problem. I'd be happy to see it merged into that > > extension. > > With the caveat that this really should be part of the (mythical) central > code repository, which is currently wanted by lots of people [..] What central code repository are you talking about? I suspect you might refer to the concept of a central wiki for one or more of templates, gadgets and lua modules. This does not overlap with global user modules and would be hard or inappropriate to utilise for this purpose I think. (In reply to comment #23) > If it's part of CentralAuth, I'm pretty sure we can get it rolled out. If it > a separate extension, I'm not sure. The separate extension already existed, and is now being rewritten. It will be using similar methods, but will require proper extension review nonetheless as it isn't a straight copy from the patch (and couldn't be). (In reply to comment #24) > @Krinkle: Is deploying it in a separate extension okay for you? I'm okay with us reviewing, maintaining and deploying this as a separate extension. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
