This ticket seems to mix "Somehow set view policy for tasks created via email" and "Attachments are not attached on tasks created via email" (example, please) ?
That's more than one issue per task and thus not actionable. ;)

I can reproduce.

Hi @XCBRO172, thanks for taking the time to report this. Please provide an actual list of steps to reproduce, step by step. The list above are no steps to reproduce.

Done!

@Qbli2mHd: Is there any existing CSS for this? I don't see (so far) how this is a MediaWiki specific problem; sounds like a problem that could happen on any website?

Thanks for reporting this, however Wikimedia cannot do anything about a misconfiguration on a third-party website. Please take a look at error logs or the developer tools of your web browser to see the actual error message. You could also ask a support question on https://www.mediawiki.org/wiki/Project:Support_desk if you are running that website. Thanks!

Hi @Danny_Benjafield_WMDE, please associate one or more active project tags with this task (via the Add Action... → Change Project Tags dropdown). That will allow to see a task when looking at project workboards or searching for tasks in certain projects, and get notified about a task when watching a related project tag. Thanks!

thumbnails do not appear on Wikisource, no matter purging is done:
https://en.wikisource.org/wiki/File:Literary_forgeries,_by_James_A._Farrer,_1907.pdf

"smart" is often a buzzword which has no meaning to me. What are you actually after? Better readability? Something else?

Not sure if data inside of that <dd class="info"> can have any linebreaks... Would some CSS to use background colors and/or fonts like

I'm pretty much like T434144#12196588 - you listed some situations above (thanks!); it's unclear to me if in these situations, the initial position of whatever a 'dialog' currently shows could already be improved, so moving a dialog window should not be needed anymore.
Asking as I've seen many modern applications move away from draggable/moveable dialogs as they can get in the way when interacting with the content displayed in the application itself. Instead such dialogs have been moved to static positions like a bottom bar, or in a top right position in LTR context.
But I can also understand that this is a quite different UX interaction concept which may not fit here.

See T434355: Create a non-modal dialog window for Codex and T434356: Create a draggable dialog window for Codex for potential followups.

This seems to be about Codex, thus adding the Codex project tag

This seems to be about Codex, thus adding the Codex project tag

Cannot reproduce anymore with the given steps above; assuming this has been fixed in the meantime.

Wow. What's with the attitude in this task?

This ten year old ticket has no open subtasks (anymore) and doesn't really look like serving a purpose (anymore).

No reply; closing.

Opinions welcome.

Closing in favor of https://github.com/magnusmanske/quickstatements/issues/51 as that's where the tool's issue tracker is located (it's up to maintainers if they want to use Wikimedia Phabricator or something else...)

See for example https://www.mediawiki.org/wiki/Help:Images#Stopping_the_text_flow how to avoid that via content.

Nemoralis edited projects, added: Wikimedia-Site-requests; removed: MediaWiki-Internationalization.

Hmm, sorry. I'd recommend to also bring this up in a support forum to maybe gain more traction: https://www.mediawiki.org/wiki/Communication

Boldly resolving as all subtasks are closed and T178867 is resolved. Shrug.

Does this open ticket still serve some purpose? All its subtasks are closed.

Thanks!!

Is this really a ticket to keep opened or has it served its purpose? Asking as the last ticket update took place in March 2025.

Proposing that this is unlikely to happen as it has not happened for the last one and a half years, that the wiki page is probably quite alright as it is, and to close this task by setting its status to resolved.

Sure sure, I've updated H476 accordingly now to also include serviceops-radar in the condition

Boldly declining for now per last two comments; please reopen if there is a point that I missed. Thank you!

Archived https://gitlab.wikimedia.org/admin/groups/repos/api-platform.
Did not find anything related in Diffusion, thus removing that (default) project tag.

Again, your "basic stuff" is not other people's "basic stuff", I'm afraid.

Would rephrasing the output Please use Codex instead. to Please use Codex (or worse, OOUI) instead. resolve this?

Makes sense to me but I'd love to see input / awareness from Product Safety and Integrity folks. (It'll be Mute until someone renamed Mute in the software.)

@Sophivorus: Could you please answer the last comment? Thanks in advance!

No updates; unfortunately declining for now. :(
Please reopen this task once there is some progress - thank you!

@dmiranda: What's the FR workflow? Can this ticket be "resolved", or is there more to do? Thanks.

Sorry for the late answer.
I'm not sure what to make out of this:

debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.

Closing per T407967#12195231 and the previous comment here.
Not sure it's solved in the codebase but the problem should not be visible anymore in this very downstream instance.

I believe that https://gerrit.wikimedia.org/r/c/labs/striker/+/521367 and especially https://gitlab.wikimedia.org/repos/phabricator/phabricator/-/commit/b9ce09293b02e2d3b042740a518c7778a08fcd98 have resolved this by now.

Closing per last comment; author is not available anymore.

No reply; assuming this is resolved also in my understanding

master branch deleted via https://gerrit.wikimedia.org/r/admin/repos/phabricator/antivandalism,branches

Cannot reproduce the exact problem shown in the screenshot, and I don't know where the "500 chars wide" statement in the task title comes from...