This task doesn't describe a root problem. See Contributing Feature Requests for modern documentation on feature requests.

In any case, we can't reproduce this and aren't sure if it reproduces at HEAD. See Contributing Bug Reports.

See also D14665 for EditEngine integration, which slightly changes one call.

Cool, let us know if you run into anything else.

Yeah, I upgraded my dev instance to Head which doesn't have this issue. Thanks!

(At the least, I can't reproduce these issues at HEAD.)

You're a few days out of date -- I believe both of these issues are fixed at HEAD. Can you upgrade and let me know if you're still seeing issues?

I don't know how to reproduce this, either. This may fix itself as T9132 evolves.

Fixed in HEAD (D14571).

Thanks! Should be fixed in HEAD.

I'm partly just guessing here but I think It's almost certainly my fault.

Thanks, I spent ~10 minutes on it but couldn't figure it out.

File should be getting attached to the paste, but isn't. I think I accidentally caused a side effect here when changing how the transaction works.

Actually something weird is going on... I can't edit pastes either, even if the Edit Policy is set to "All Users".

I'm not sure how to fix this without adding pastePHID to PhabricatorFile, which doesn't feel like the best approach.

I started looking at this. It seems like the file attached to the Paste has a view policy of no-one, whereas it should probably inherit the view policy of the parent Paste.

• I cherry-picked this to stable (rP111c48b2).
• I deployed this fix to the Phacility cluster.

Wasn't aware of this one, thanks.

The ability to fork Pastes was removed in D14390.

Upgrades are cool!

Upgrade to fe7d8c2.

There's a vaguely related but much less severe issue where the list view can take a long time to load because it needs to pull a bunch of files off S3 in order to generate the content caches.

I tried implementing this myself but got a bit stuck. Since lines and line limit is passed to PhabricatorSourceCodeView from PhabricatorPasteSearchEngine::renderResultList() this looked like a good place to start, and pass line length limit. The problem I've encountered is that PhabricatorSourceCodeView receives lines already in HTML. Even though stripping tags and converting HTML entities back to original characters to get line length is easily doable but seems a bit awkward. And then truncating HTML markup is even more problematic...

Ohhh! Sorry, we usually use "preview" to mean "remarkup preview" (the comment box thing at the bottom of the page) and I figured you were putting {P123} in a comment and getting slow comment previews.

This is about Paste application index page. I guess more generally speaking it would paste search query result list.

From T9566, these are probably 1MB JSON blobs from API calls.

Out of curiosity, why use Paste for that much code?

That was just some random demo user clicking buttons. I'll merge 'em.

I'm not sure this is related to "T9415: PhabricatorApplicationTransactionPublishWorker requires unreasonable amount of memory for large numbers of mail recipients?".

Quotes also don't work in Ponder.

I'm not able to reproduce this at HEAD. Are you sure your install is up to date? We expected D14063 to resolve this. If this still reproduces at HEAD, can you give us a better idea of OS/Browser for testing?

Regarding mixed-language environments (like sql appearing in a python script), most editors would simply look at the file extension and highlight the entire file in that language (in our example, python.. and the inline sql might appear in the color of a string).

You don't actually care about download/view (i.e., the Content-Disposition of the response), you just want a URL which shows the current contents, right?

@epriestley Thank you very much! Restarting php-fpm (sudo service php-fpm restart) fixed the issue. :)

Does restarting apache (or php-fpm, if using php-fpm) fix this?

Maybe I should check this without our patch. But the patch only regards some files in Phrequent.

To be honest, the paste I was archiving was a fork of another paste which I generated when I wanted to find out how forking a paste works.

I can conceivably land that, I think it just never quite felt right to me. Maybe I'll take another look at it in the new design.

D8685 is also maybe related, though we never experimented with that live.

One mild concern I have with merging these into "Edit" is that the effects of disabling things aren't always self-explanatory, and this dialog gives us an opportunity to explain effects.

My main question here is, how often are you archiving Pastes? Is this a one-time clean up or do you do this weekly and archive a dozen and it's very painful? Overall, T9132 would be the most optimal route for mass-archiving.

Paste, Pholio, Dashboards, Owners, Badges all work this way. The main reasoning is these items are not usually globally owned (actually Pholio is now) and therefore the vast majority of views will have an action that cannot be taken. I'm personally very hesitant to add additional actions to the action list, specifically it increases the cognitive load on the user and if they won't be able to take the action, it's just clutter.

Owners and Badges also have this inconsistent archiving flow.

Could this be part of T9132? Seems like one 😉

(I did fix a couple of similar things a while ago, so it seems reasonable that this may be resolved at HEAD.)

Oh! Sorry, ignore me.

Well.... it was current when the task was filed.

Yeah, you're about two months out of date. Does updating fix the issue? See:

I can't reproduce anything here, does this still give you an error at HEAD?

Ah, that's how to do it. Create a saved query and then have the dashboard pick it up. Thanks for the info. I was unaware of how dashboards interacted with the rest of the searching infrastructure.

Authored just means Authored. It's not Authored, Active.

I meant, in the dashboard view: https://www.dropbox.com/s/ud2vy3nfvjd20n4/Screenshot%202015-08-08%2013.24.58.png?dl=0

It works for me:

@chad it isn't possible to search for 'my active authored pastes' which is what we'd like to show in the dashboard. Is this intentional?