Deleting the branch first won't have any effect, since the commit still exists.

Sounds like a dup indeed. What's the work around?

• Doing a rebase instead of FF-merge?
• Deleting the topic branch in Diffusion first, then FF-merge and push?

BTW is the print action the expected method to get an "invoice" for my records? Or can you download a formal invoice from somewhere?

OK I understand. Even if the current UX is not perfect, if implementing an improved version would result in a more fragile UX because the code is a lot more complex, then yes, the current situation is preferable.

Ah I was wondering about this comment, but since it was explicitly hidden, I thought it wasn't the cause.

Thanks for looking into this @epriestley!

You can either solve this by not sending such emails when a task is merged (but they you don't notified of merged tasks which is bad), or by having a dedicated subject / body for merged task notifications, which then:

1. solves this bug
2. improves the UX since you now get a notification email that actually reflects the action that happened

I really don't think this task should be closed. This is a user experience bug, independently of any underlying good reason there might be in the implementation.

It looks like the changed subscribers results from a merged task, so maybe this case is not handled?

The best might be to have a configuration option for this linter to add extra allowed characters.

If you have this in mind, I'm not looking for batches renaming or anything like this.

That's already the root problem 😉

I'm using the reload button next to the URL field indeed. I'm not sure this trashes the cache because if that was the case, there would be no 304s, right?

Thanks @epriestley, much looking forward to have this deployed to Phacility.

I'm on my laptop using tethering on T-Mobile right now and I just noticed the user profile photos in the workboards are not being cached. Whenever I reload the page (Chrome 49.0.2623.110 on OS X 10.11.4), these photos reload from scratch. Here are the headers as reported by the Chrome inspector:

Thanks much for the info. What should happen with this very task then? Close it?

The 'mild redesign' we've been rolling out will have a fixed-width option likely per user under Accessibility

It's just one of those design/usability tenants, whitespace improves visual comprehension. Plenty of usability research out there supports this.

Stuff like this:

Wikipedia, the ultimate wiki, is full page width (https://en.wikipedia.org/wiki/Phabricator).

When I said "user images" above, I meant to say "user uploaded images" like what you drag & drop in Pholio, Phriction, Maniphest, etc... i.e. explicitly not Phab built-in images which are indeed cached. Sorry if that was confused with "user profile images". There are no performance problems here. In general I have observed no performance issues with Phacility outside of the matter tracked by this very task.

Here's another big problem (IMHO) I just realized: using Phab on mobile or through tethering on your laptop is terrible: the fact user images don't get cached, kills usability: it takes forever to load / reload anything with user images.

I was expecting this "parameter" to be a checkbox that could be turned on / off on the diff itself, and editable through the creation and edit forms, not through the action system, if that makes sense?

No to beat on a dead horse, but I just finished creating a new wiki page with ~20 screenshots of mobile UI (in a series of tables to easily compare UIs on different OSes), and the fact images don't cache is a massive pain:

• whenever editing the markup, even to add a single character, the preview area needs to reload 2+ MBs of screenshots
• not only is this slow, but the layout of the preview jumps all around while the images are (re)loading, so you can't navigate easily
• same thing when saving the changes: everything needs to reload again from scratch and layout jumps again all over the place

One of the fundamental features I really like about Phab is how everything is linked nicely: from diffs to tasks to commits to wiki etc... Seems like Audits are surprisingly silo'ed from the rest.

A generic Phab icon would be fine for a first pass at improving this IMO.

Thanks! I shall use these powers responsibly 😄

Oops... sorry, can't believe I missed that! I was looking in "Commit Hook: Branches/Tags/Bookmarks" instead of "Commit Content".

Understood. I'm of the very same opinion when it comes to adding settings / preferences to a product. It shouldn't be a way to avoid taking a decision or pushing the problem to the user.

Naive question, but would it be possible to have a new "disable security theater" setting and have Phab then do "Unique URL Hash + Fully Cacheable Resources" like everyone else?

I've rebooted the Windows VM and haven't seen this issue in a few days. So we're good. Thanks for the help.

It should not require more than 60 seconds, but rather less than 1 second. Only the Jenkins instance running inside a Windows VM has this intermittent bug though. So it still sounds like a reasonable explanation: maybe Jenkins in Windows gets suspended if not used for some time or the VM itself is paged out on the host HW and takes forever to become responsive, who knows...

BTW I realized I forgot to specify in the description of the task that what I'd like to know is why do the logs look like this and what is error 28? Does this come from Phabricator? Is there a lower-level log one could look at?

Actually all build plans show these duplicate steps. Is this an (unrelated) bug?

OK I just noticed this build plan as 2 duplicate steps (with the same 1.1 identifier)? That certainly shouldn't be the case. Did something get corrupted?

Great, thanks @epriestley!

Is this the only case of remarkup syntax that is tied to having an app enabled? This should really be documented in https://secure.phabricator.com/book/phabricator/article/remarkup/.

Yeah, I don't think it used to be like this ~1 year ago.

Our instance is "hyper" BTW if this helps.

Yes, Macro is uninstalled.

FWIW I'd be happy to trade performance for security by obscurity aka Facebook model etc... when it comes to files stored in Phabricator - because right now on Phacility, the current approach makes wiki pages with numerous image files feel slow since images are not cached at all. And we don't have anything that sensitive. Maybe a config setting could allow this?

If I switch the setting to ["http","https","mailto","hyper","itms-services"], then the exception is gone. So I guess the format is a JSON array, not object. But like I said above, hyperlinks don't work at all.

Ah and when I attempt to save the doc, I get this error:

Unhandled Exception ("InvalidArgumentException")

Still doesn't seem to work: all links are broken in Phriction:

What's the format for setting? I tried ["http","https","mailto","hyper"] but it didn't work and actually breaks all links.

I'm not sure what you mean by "from the instance panel"? Is it the instance's regular config page?

Ah. I searched for something like this in config but forgot about the /config/all/ page.

Great, thanks much for the incredible responsiveness 😄

@epriestley Are you sure inline works?

{F60 width=160, layout=inline}  {F60 width=160, layout=inline} {F60 width=160, layout=inline}

Yep, table works, thanks for the idea!

Is there any markup command to "clear the float"?

Yes, please add a workboard setting to display all projects on card. My previous request above is almost a year old and user demand has not diminished.