See also:

In T332850#8721037, @Bugreporter wrote:

If the issue is severe enough as T257062: Lilypond seemingly not subject to restrictions (CVE-2020-29007), it should be emergency disabled but reenabled once it is fixed (and there would be a task for reenable it).

See also: T32861

I uploaded a patch for this task in Phorge upstream: https://we.phorge.it/D25068.

Open states such as In Progress and Stalled are displayed on workboards now so it must have been implemented by the upstream at some point.

Unless you want to edit another user's patch, you don't need to. You can still create and edit your own patches.

It's because you need to be in the Gerrit Trusted-Contributors group to edit another user's patch.

You can already use the Gerrit web interface to make simple changes. T329726 is unrelated to the web interface, you would still be denied even if you used a command line.

I created a fix for this in Phorge upstream: https://we.phorge.it/D25067 / https://we.phorge.it/T15146. In the mean time, someone may be able to fix this just by removing and re-adding the "Newcomer tasks" tab until the bug goes away (the bug is a type juggling issue related to the tab ID, see the upstream task for explanation).

Screenshot from above patch:

Just to clarify (our Phabricator has quite a complex permission hierarchy), @Stevemunene was able to add themselves because they were already a member of acl*sre-team. acl*sre-team grants edit access to acl*security, and anyone with edit access on a parent project can edit a subproject, and anyone with edit access can also join that project (see https://secure.phabricator.com/book/phabricator/article/projects/#parent-projects). Therefore they were able join acl*security_sre because is is a subproject of acl*security which they could edit. FWIW Security is not supposed to be used for permissions in any way, as it is joinable by anyone, it is just for tracking tasks.

It was actually assigned to the correct account, but a spam user changed it here: https://phabricator.wikimedia.org/diffusion/identity/view/33242/ which wasn't reverted unfortunately, probably because it is pretty obscure and doesn't show up on the accounts activity.

Error is gone. I guess someone has fixed it.

Not a bug (MediaWiki doesn't understand "për sempe"). You can also just choose other and type "infinite".

I'm pretty sure this is because their MediaWiki:Ipboptions message is incorrect (they've double translated the English and localized text). I recommend just deleting the message.

This is just a side effect of aggressive RAM management on iOS/Android. There isn't any solution to this apart from persisting the progress so that it is reloaded when a user returns, which would probably require a lot of work to do.

acl*phabricator can also create custom maniphest forms, full administrator is not required.

It's a concatenation of the localized name of the "contributions" special page. On French Wikipedia the special page is just called "contributions" and the message exists so the message is displayed. Another example of this bug is on Spanish Wikipedia where the localized contributions page is called "Contribuciones" and Special:Contribute shows message key "special-tab-contribuciones-short". It should probably concatenate the English name of the special page rather than the localized name?

This error could also be caused if Phabricator was updated but not Arcanist, or vice versa. The error is output here https://github.com/phacility/phabricator/blob/9426765a2c6a149f5b0ed2d9132cd1e4e7ee152d/scripts/init/lib.php#L14

There's nothing sensitive you can do on that page, MediaWiki already breaks frames on sensitive pages with x-frame-options. Unless the user can be tricked into performing some action, then there's no clickjacking attack present.

https://mediawiki.org/wiki/Extension:UrlGetParameters already adds a parser function to get a url parameter.

https://secure.phabricator.com/rP2167016aebba5952a33d3f3c304533f8756072a5 fixes this.

{D1203} adds support for all upload workflows, so you can use the edit form upload dialog, copy-paste, or drag-and-drop. Resolving T310850 alone will fix attachment workflows for copy-paste and drag-and-drop though.

Removed Release Version which seems to be causing this error as it was formatted in a non-standard way.

I don't think this is new behavior in that they have always defaulted to the uploader. It's just noticeable now because files don't get attached automatically. They should get automatically attached when you drag-and-drop, but this isn't working due to T310850.

In T307750#8009866, @Aklapper wrote:

I assume that T309430 will fix this

It wasn't broken by an upstream change, it was only deployed today and the change doesn't work properly because only ManiphestTaskMergeInRelationship and ManiphestTaskCloseAsDuplicateRelationship specify a value in getMaximumSelectionSize(). This means other relationship types default to null here: https://github.com/wikimedia/phabricator/blob/0f94052396d1a7f1da1d0ed48a414c388efe38b3/src/applications/search/relationship/PhabricatorObjectRelationship.php#L108.

Actually, there is a deployment next week and there are scn translations in the repository, but according to rPHTR Phabricator Translations, the language needs to be added to src/locales/ before it will show up. Which I'm not sure I fully understand since there are languages in settings which have translations, but don't have a file in that directory (e.g. zh-hans/zh-hant).

This should get deployed this coming week.

This is due to cached HTML from the previous image being returned:

	/**
	 * Returns the text content of a html string, with the `<a>`, `<i>`, `<b>` tags left intact.
	 * Tries to give an approximation of what would be visible if the HTML would be displayed.
	 *
	 * @param {string} html
	 * @return {string}
	 */
	HUP.htmlToTextWithTags = function ( html ) {
		var $html;
		if ( !cache.textWithTags[ html ] ) {
			$html = this.wrapAndJquerify( html );
			this.filterInvisible( $html );
			this.appendWhitespaceToBlockElements( $html );
			this.whitelistHtml( $html, 'a, span, i, b, sup, sub' );
			cache.textWithTags[ html ] = this.mergeWhitespace( $html.html() );
		}
		return cache.textWithTags[ html ];
	};

jQuery object gets converted to array key [object Object] which results in ununique key and causes incorrect cached HTML to be returned:

} else {
	this.creditField.set(
		$( '<a>' )
			.addClass( 'mw-mmv-credit-fallback' )
			.prop( 'href', filepageUrl )
			.text( mw.message( 'multimediaviewer-credit-fallback' ).plain() )
	);
}

Object { "Test": "Test", "[object Object]": "<a class=\"mw-mmv-credit-fallback\" href=\"http://localhost:8080/wiki/File:Test.PNG\">View author information</a>", Capture: "Capture" }
mmv.HtmlUtils.js:234:11

Though the policies of acl*wmcs-team and acl*blog-admins should probably be modified to remove Policy-Admins if there is no need for it.

Or you can just use doApiRequest and pass the token yourself. E.g., https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master/tests/phpunit/includes/api/ApiLoginTest.php#121.

It's not really non-standard. lots of APIs have prefixes to prevent parameter conflicts. Submodules of query (which checkuser is) must have parameter prefixes, so removing the prefix is not an option.

Release-Engineering-Team now references it correctly (with #acl_releng). Project hashtags can't contain special characters like *, so referencing the project using special characters won't work properly. Special characters should automatically be converted to an underscore when a hashtag with special characters is added.

Not sure if this is a new feature, but when you change the filter it posts to /settings/adjust/?key=search-scope. So you should only need to change it once. But the default can also be changed for everyone by administrators in the global default settings page.

This was deployed in https://phabricator.wikimedia.org/rPHDEP68b31a2817686c9b4d7113a73b017ee3ce4a5bdd.

The link to create a blog is https://phabricator.wikimedia.org/phame/blog/edit/. Any user in acl*phabricator can do so.

Are people still interested in something like this? I was experimenting with this and created a working prototype, it requests all Gerrit patches using the task IDs and then extracts and caches an array of the relevant data from the Gerrit changes, it's similar to the current Gerrit patches fields on tasks:

https://secure.phabricator.com/w/changelog/2022.21/ essentially resolves this as attachment behavior is changed so that files are only attached when you drag a file into the comment box. If you simply reference the file, it will not get attached so it will not inherit the permissions of the object and will stay private.

Seems this is no longer reproducible: https://phabricator.wikimedia.org/badges/view/10/#671.

T270696 @gerritbot @Dylsss @bzimport

It's from https://phabricator.wikimedia.org/source/phabricator/browse/wmf%252Fstable/src/applications/people/xaction/PhabricatorUserEmpowerTransaction.php$35. If the aim of this task is to allow Phabricator admins to remove their own admin status, then the if condition just needs to be removed.

The below should prevent non-public project columns from being returned:

diff --git a/wmfphablib/phabdb.py b/wmfphablib/phabdb.py
index e0f7f0b..1376a5f 100755
--- a/wmfphablib/phabdb.py
+++ b/wmfphablib/phabdb.py
@@ -17,7 +17,7 @@ from config import bzmigrate_user
 from config import bzmigrate_passwd

Was done in rPHEX1d9b463a4f1cb540fc6922b64a8d6bbc130a62f9.

Seems to be caused by the iiurlwidth=800&iiurlheight=400 parameters.

The API request that FileImporter is making is https://beta.wikiversity.org/w/api.php?action=query&format=json&titles=File%3AJoonitud_EMH_3196_2.tif&prop=info%7Cimageinfo%7Crevisions%7Ctemplates%7Ccategories&iilimit=500&iiurlwidth=800&iiurlheight=400&iiprop=timestamp%7Cuser%7Cuserid%7Ccomment%7Ccanonicaltitle%7Curl%7Csize%7Csha1%7Carchivename&rvlimit=500&rvdir=newer&rvprop=flags%7Ctimestamp%7Cuser%7Csha1%7Ccontentmodel%7Ccomment%7Ccontent%7Ctags&tlnamespace=10&tllimit=500&cllimit=500. Which returns Could not normalize image parameters for Joonitud_EMH_3196_2.tif.

Also is F21966 considered private, as it was previously set to WMF-NDA.

This is now fixed in Phabricator upstream, there is now an advisory at https://secure.phabricator.com/T13683 and change summary at https://secure.phabricator.com/w/changelog/2022.21/. This task has details of the attack that were purposely omitted and undisclosed in Phabricator upstream, so I am temporarily adding PermanentlyPrivate to prevent this task from being made public.

This is intended, the API response specifies the prefix "prefix": "lg". You append the prefix to the parameter names.

I think this is the same as T291775 and T258803.