Page MenuHomePhabricator

Merge RenameUser into core
Open, NormalPublic

Description

It really should be core functionality...


Version: unspecified
Severity: enhancement
URL: http://www.mediawiki.org/wiki/Extension:Renameuser

Details

Reference
bz25482

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 21 2014, 11:16 PM
bzimport set Reference to bz25482.
bzimport added a subscriber: Unknown Object (MLST).
Reedy created this task.Oct 10 2010, 7:11 PM

This extensions was bundled (by you) :) and it sits now under "Closed" at http://www.mediawiki.org/wiki/List_of_extensions_to_be_merged_to_the_core#Renameuser

There hasn't been any progress here since 2010. Should we resolve this as WONTFIX?

Reedy: Could you answer comment 1, please?

(In reply to comment #1)

This extensions was bundled (by you) :) and it sits now under "Closed" at
http://www.mediawiki.org/wiki/
List_of_extensions_to_be_merged_to_the_core#Renameuser
There hasn't been any progress here since 2010. Should we resolve this as
WONTFIX?

I think we should do this, rather than just bundling the extension; it's what people will expect of administrator toolsets nowadays.

(In reply to comment #3)

There hasn't been any progress here since 2010. Should we resolve this as
WONTFIX?

I think we should do this, rather than just bundling the extension; it's what
people will expect of administrator toolsets nowadays.

Closing. Please reopen if you disagree.

I think by "we should do this", James meant "we should merge it into core".

Agreed; this is something we should merge.

CC'ing Chris who would be most likely the one responsible. (Sorry, Chris. :-))

It'd be awfully nice to clean up the database schema before doing this, but it's not strictly a blocker.

Please give a deeper elaboration reason other than "we should" when we already have bundled in the installer.

(In reply to comment #8)

Please give a deeper elaboration reason other than "we should" when we
already have bundled in the installer.

See comment 3.

"[W]e already have bundled in the installer" means that *some* people (who use the tarballs, which is far from all our downstream users) will probably, hopefully have it available. That's not sufficient for what is an expected piece of fundamental account management (for anti-vandalism purposes, account management and others).

(In reply to comment #9)

...snip...
"[W]e already have bundled in the installer" means that *some* people (who
use
the tarballs, which is far from all our downstream users)

basically its most people apart from

A. Directly setup from out VCS (I'm sure they can manage installing a extension)
B. People who install from OS-Packages (Which afaik we don't really support anyway, And could bundle the extensions into a seperate package file like they used to do for maths supportor they could probably still do it normally in the installer )
C. CPanel/Fantastio/etc users

There has been numerous discussions on the lists and IRC channels about Bundling in Core vs Bundling ext in the installer package, And I haven't really be swayed away from the latter yet in-regards to the bigger picture.

(In reply to comment #10)

There has been numerous discussions on the lists and IRC channels about
Bundling in Core vs Bundling ext in the installer package, And I haven't
really
be swayed away from the latter yet in-regards to the bigger picture.

Indeed, there's been a fair amount of talk about it. But I don't think there's one fixed rule, like "Always/Never make it an extension if you can".

It depends on how, well, core, the functionality is. If it's something every wiki, or almost every wiki, needs, that's an argument to move it to core. Doing so can sometimes allow structuring the code in a simpler way.

I agree, it should be merged into core. Would a patch to accomplish that be accepted?

(In reply to Nathan Larson from comment #12)

I agree, it should be merged into core. Would a patch to accomplish that be
accepted?

If it's just the current code in the extension, I would say no. I do agree that renameuser-functionality should be in core though.

Special:Renameuser's code is a mess, and should be re-written with FormSpecialPage. The logic should also be abstracted into its own class so make adding an API module trivial.

Also it doesn't support shared user tables, which would be a blocker IMO (though, that would probably just work if bug 31863 was fixed).

Ricordisamoa added a subscriber: Ricordisamoa.
Paladox set Security to None.Sep 11 2015, 8:52 PM