ORES extension should not modify $wgHiddenPrefs at runtime
Closed, ResolvedPublic
Actions

Description

In PreferencesHookHandler::onGetPreferences():

		// Hide RC/wL prefs if enhanced filters are enabled
		$context = new DerivativeContext( RequestContext::getMain() );
		$context->setUser( $user );
		$context->setRequest( new DerivativeRequest( $context->getRequest(), [] ) );
		$rcFiltersEnabled = Hooks::isRCStructuredUiEnabled( $context );
		// HACK: Note that this only hides the preferences on the preferences page,
		// it does not cause them to behave as if they're set to their default value,
		// because this hook only runs on the preferences page.
		if ( $rcFiltersEnabled ) {
			$wgHiddenPrefs[] = 'ores-damaging-flag-rc';
		}

That's really evil. There has to be a better way to do this.

Related Objects

Mentioned Here: T180866: Rationalize ORES preferences on Recent Changes and Watchlist prefs pages

Event Timeline

Legoktm created this task.Nov 21 2017, 1:03 AM

Restricted Application added projects: Collaboration-Team-Triage, Machine-Learning-Team. · View Herald TranscriptNov 21 2017, 1:03 AM

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

It would be great if there was. We tried to find a better way of doing this when doing a similar thing in core(!), but couldn't really figure anything out there either: https://gerrit.wikimedia.org/r/#/c/388264/13..14/includes/Preferences.php

Maybe this is a feature that we should add to the preferences system? Or can it already be done and are we missing something?

In T181015#3776590, @Catrope wrote:

It would be great if there was. We tried to find a better way of doing this when doing a similar thing in core(!), but couldn't really figure anything out there either: https://gerrit.wikimedia.org/r/#/c/388264/13..14/includes/Preferences.php

This is definitely not acceptable for core :/

Maybe this is a feature that we should add to the preferences system? Or can it already be done and are we missing something?

Can this be done with HTMLForm's hide-if functionality? Or maybe just some JavaScript that hides it from the UI depending upon the other value kinda like HTMLSelectOrOther.

I see this is about hiding the ORES prefs when the New Filters are active. I just filed a ticket—which @Petar.petkovic is working on—that ends the practice of hiding and showing preferences based on the New Filters status: T180866. So does that resolve this?

It might? I'm not sure tbh. We can keep this one open since it's a specific tech debt issue, and if fixing that bug happens to fix this one as well, that's great :)

In T181015#3778532, @Legoktm wrote:

It might? I'm not sure tbh. ...

@Petar.petkovic, will it?

In T181015#3778540, @jmatazzoni wrote:

In T181015#3778532, @Legoktm wrote:

It might? I'm not sure tbh. ...

@Petar.petkovic, will it?

I just checked and his WIP patch does in fact remove all $wgHiddenPrefs usage.

In T181015#3778680, @Catrope wrote:

I just checked and his WIP patch does in fact remove all $wgHiddenPrefs usage.

So should we resolve this?

Yes, I did remove this piece of code in my WIP patch. Reopen the ticket if you deem necessary.

Thank you @Catrope for answering.

isarantopoulos moved this task from Unsorted to 2023-2024 Q3 Done on the Machine-Learning-Team board.Nov 20 2023, 12:18 PM

ORES extension should not modify $wgHiddenPrefs at runtimeClosed, ResolvedPublicActions

Description

Related Objects

Event Timeline

ORES extension should not modify $wgHiddenPrefs at runtime
Closed, ResolvedPublic
Actions