It looks like there's a 3-step workflow for making attached images public (if we used drag-and-drop to upload). I will test it on these 3 files, but leave out the original in the Description.

I'll put some money on this upstream change having something to do with it, if only from the name of the file changed.... "webroot/rsrc/js/core/behavior-drag-and-drop-textarea.js"

However if we use the "upload file" form, then things work as expected.

for me this issue is also present when I use the "upload file" form. just added an image test to T306562 via the "upload file" form.

logged in	logged out

(note: the images in this comment were uploaded using the "upload file" form, then edited via the phabricator URL, e.g. https://phabricator.wikimedia.org/F35247591)

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.

Note this also applies to copy and paste, which is the workflow I use the most often for partial screenshots. Hopefully any fix will apply to both use cases, but just a note that to test that as well.

I think it's mostly working as intended but is a fairly bad user experience and may have glitches.

This seems like a particularly bad user experience -- I'm not sure I've ever used the upload form, I mostly copy-paste screenshots in, with occasional drag-drop.

It does sound like Phabricator is supposed to already be coping with this, from the upstream ticket:

However, Phabricator can determine that an attachment is expected and safe in some common cases, like dragging a file into a comment area: when you do this, Phabricator will automatically generate an appropriate "attach file" action as part of the comment.

So maybe the current bad behavior is a temporary glitch and can be quickly fixed? But of course...

These behaviors may improve in a future release of Phabricator, but see also the "no longer actively maintained" banner and don't hold your breath.

{F35249270}

D1203: Support automatic file attachment in most upload workflows 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.

Isn't it funny that this thread contains images I can't see? Namely https://phabricator.wikimedia.org/F35249270: "Access Denied: Restricted File. You do not have permission to view this object. Users with the Can View capability: @DLynch".

My team is currently running into this with every screenshot we try to attach to a ticket. The experience is rather painful, and I find it very unclear how to resolve from it. For example, I found these red "File Not Attached" warnings in the sidebar on the right. I can click it and confirm the two popups that show up, and the red warning disappears. Still when I look at the file individually it still says I'm the only one who can view it. What's going on?

TL;DR: Can we please make files public by default, as it was before?

@thiemowmde This will be resolved once our Phabricator deployment is fixed, see T310850. As I understand, it has a build process you have to execute before deploying, and was executed wrong or something. Phabricator's actual code handles this correctly, when it's deployed correctly.

In T310833#8014589, @thiemowmde wrote:

Isn't it funny that this thread contains images I can't see? Namely https://phabricator.wikimedia.org/F35249270: "Access Denied: Restricted File. You do not have permission to view this object. Users with the Can View capability: @DLynch".

I thought that was the joke :)

My team is currently running into this with every screenshot we try to attach to a ticket. The experience is rather painful, and I find it very unclear how to resolve from it. For example, I found these red "File Not Attached" warnings in the sidebar on the right. I can click it and confirm the two popups that show up, and the red warning disappears.

Clicking through those popups from the sidebar is indeed the way to resolve the problem.

Still when I look at the file individually it still says I'm the only one who can view it. What's going on?

TL;DR: Can we please make files public by default, as it was before?

This has always been the case. If you upload the file through the form at https://phabricator.wikimedia.org/file/upload/, it will be public; if you upload it while commenting on a task etc., it will be only visible to you, but it will also be visible to all subscribers of tasks etc. that it is attached to – just the internal method of attaching it has been changed. Here's an example file I uploaded last year which behaves in the same way: F34663344

Just echoing the concerns above: this is causing a lot of confusion in my team's workflow. In particular, we're getting inactionable bug reports because of restricted images, and the workflow for fixing it appears challenging.

+1 it would be super appreciated if this can be resolved soon. It is causing more work and lost time for design team folks who tend to upload a fair amount of images on tasks. Besides the added steps needed right now, the fact that a person uploading or copy+pasting can see the image makes it easy to forget to even take those extra steps to change view permissions/attach the file.

Thanks, @brennen ! I know you folks have a lot going on and really appreciate your attention on this. :)

Is this actually resolved? I saw it still occurring in a comment left yesterday (which has been manually fixed since -- the first two images were unattached, though).

Another public domain dinosaur test:

A public domain dinosaur test for the upload button:

A public domain dinosaur test for the copy-and-paste action:

I imagine it could happen if you copy-paste (or drag-and-drop) the files on one task, then cut-and-paste the {F....} markup into another task.

Here's an example, let's see: {F35284673}

And indeed. I don't think it's possible to make this work automatically with Phab's new model for attachments, though? We might want to just document how to fix it when it happens.

I imagine it could happen if you copy-paste (or drag-and-drop) the files on one task, then cut-and-paste the {F....} markup into another task.

Hmm, yeah, that seems like a plausible mechanism. I'll leave this open in case anyone has run into anything else.

And indeed. I don't think it's possible to make this work automatically with Phab's new model for attachments, though? We might want to just document how to fix it when it happens.

Yeah, I can add something to https://www.mediawiki.org/wiki/Phabricator/Help#Uploading_file_attachments

I documented it: https://www.mediawiki.org/w/index.php?title=Phabricator/Help&diff=5314372&oldid=5216014

Feel free to improve.

Thanks, @matmarex . If I'm understanding correctly, restoring the original functionality is not possible due to Phab's new model for attachments. If that's the case, while documenting how-to is important, I think it's more important for the Phab UI to give instructions. The issue I'm hearing from folks is not that they don't know how to fix the issue, but that they forget (or, in the case of bug reporters, don't realize), because it's not intuitive.

Anyone know the process for getting a UI element added? For example, a message that pops up whenever a file is uploaded/pasted/dragged-and-dropped that says "take X steps to achieve visibility."

The original functionality has been mostly restored now, as long as you don't do something craaaaazy like copy-pasting plain text markup to another task. If you just upload files on a task, they should be visible with no further steps needed. (On the other hand, I've seen two people run into this problem this week already.)

I added more details in https://www.mediawiki.org/wiki/Phabricator/Help#File_visibility and I'd be fine with just giving people this link when their files are not visible to me.

Ah, OK, great, thanks for the clarification. I'll keep an eye out.

copy-pasting plain text markup to another task

Do you mean like pasting the bracket number for an image? e.g.

{F35284673}

Yes (although I should have said "cut and pasting", because this only occurs if you remove it from the task where you originally uploaded the file, which prevents it from being attached there).

T312864 features a variant of this still happening. Jon added the second image in the description via editing the description after the task was created (but still via drag-and-drop upload), and this presumably bypassed the automatic permission setting.

Jon added the second image in the description via editing the description after the task was created (but still via drag-and-drop upload), and this presumably bypassed the automatic permission setting.

Thanks for the heads up. That does sound plausible; I'll investigate.

This also happens when editing comments.

Edit: Here's a pasted image: {F35330159}

Granted, my understanding is that "automatically enabling access to files that're in edited-content" is the exact security loophole that this annoyance was introduced to avert... but it seems like there should be some way to have phabricator notice-and-allow fresh uploads in that situation while still ignoring the hypothetical malicious contents.

Hi, adding a related scenario where an image is defaulting to Private access is when it is Copy+Pasted into a comment on a Phab task. For example in T253706#8338190