We do this as a minor extension to the typical 'land' workflow. That is we have a wrapper that causes 'arc land' to be equal to 'arc diff -m "automated bump" && arc land'. We do this so that the latest version in differential maps exactly to the one that got landed. This also always causes a comment to be created immediately before land. We could possibly work around this locally by comparing the diff in differential (with getdiff or the modern equivalent) but it would be amazing if we could just tell phabricator "we're attempting to update but don't generate a new transaction if its exactly the same).

Just to add: in a big organizations Spaces can be used to divide different legal entities in a group (or big departments).
With this use most probably the majority of the users will belong just to one space, and they will just see the (default) "public" space and their own one. That means that in this case the majority of the users will not even need the switch, but just the possibility to configure the default space for new objects to their own one (not the default "public" space).
The user configurable parameter for the default space for the new objects creation can be anyway a first step in implementing then the full functionality of Space switching.

Chrome is free to send more "If-Modified-Since" headers when you press reload than when you navigate. I have no idea what its exact behaviors are.

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?

I can't reproduce that unless I actually use the "reload" command to reload the page, which looks like it makes Chrome dump caches on my system.

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

Those changes are live on this server now, let us know if you run into issues.

D15642 has additional details, but the new header/cache behavior is:

On this:

D15641 has the technical details, but here's the behavior I've implemented:

If the unique url hash changed whenever the visibility policy changed, that would be fine.

Let me explain the WMF use case a little more. We have lots of users create public tasks, often with pictures attached, which should be private (security/privacy issues, legal issues, etc). We push notifications of new tasks to our public irc channels, and a lot of our users subscribe to huge numbers of projects. So once the task is created, the content is widely dispersed. And we need the ability to make that as private as possible.

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:

Nice catch, thanks! D15619 should fix the docs.

I think this may have broken https://secure.phabricator.com/book/phabricator/article/remarkup/#tables

@epriestley and @mattflaschen I have created a windows installer here https://github.com/paladox/Arcanist-installer-for-windows

There are free installers that create the installation we want like

I doint know if we can make it an array.

@20after4 and @epriestley may we can do

I probably wouldn't show them in the UI for now, although I don't think adding an "Other Refs" table underneath tags/branches on the main screen with, say, 5 entries and a "See All" button would necessarily be terrible if anyone can come up with a reason that users might ever care about it.

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.

User profile images should be getting cached. For example, your profile image here:

I've really never experienced any poor performance when using phabricator. It's not blazing fast but that is mostly due to the complexity of the server side php bits. I have literally never seen slowness in loading static resources.

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.

Wikimedia is definitely interested in this one.

@csteipp was one of the people who originally advocated for such strict file visibility enforcement. He would be the best one to respond with justification for wanting the feature in the first place.

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

T10469 is probably the best solution there.

One followup request from D14935: Show the workboard column along with the project. Obviously there is a space vs information value tradeoff, but if workboard columns are relevant anywhere wouldn't it be in Workboards? This was feedback from one of our product managers who looks at many different workbaords, not just a single team's.

See Prototype.

Right now, the main concern is trained employees moving cards on the workboard and accidentally changing priorities (due to sorting by priority), so I agree that improving the UI would be the higher priority. In the meantime, perhaps we'll patch our instance with https://secure.phabricator.com/T8135#130563 to prevent the surprise priority changes.

Why are users who shouldn't be changing priorities doing it?

The concern that @magcius mentions is that we (Endless Computers) only want team leads to have permission to triage priority. We set that up by restricting who has access to forms that allow editing priority. But the priority-sorted workboard defeats that form-based protection. Is there some other way to configure who has the ability to triage priority?

See T10333 for plans to make dragging cards in sorted workboards more clear (and T8135 for additional discussion). Those UIs aren't as clear as they should be and we'd like them to be more clear.

We might still need this. We use priority aggressively for feature planning, and make sure only team leads can triage and adjust priorities.

In T10262#165087, @swisspol wrote:

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?

In some cases, the effects of the theater can be mitigated issue-by-issue. For example, we may be able to write caching/rendering logic in Javascript to mitigate the performance impact on lightboxes and Pholio. We may be able to attach images directly to email. There may be a workaround for the Safari issue, or we may be able to do preview rendering partially in Javascript. With Quicksand, we can also increase the "hit rate" of client-side Javascript caches, at the cost of additional complexity.

I imagine we also want to just remove the feature, but some install(s) rely on it? The point of this task then is to be a discussion around removing it outright, and giving those who rely on it time for input.

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.

I'm strongly resistant to that, see T8227.

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?

This one's slightly trickier than T10570 because leading whitespace is semantic in lists.

See T10333

Not sure if this is the right place to request for this, in an earlier build, the cards have username of the task owner on it, which is convenient to do a quick search using Ctrl+F to find tasks by a particular username. In the latest stable build, usernames on the cards are replaced with user photos instead, which makes Ctrl+F by username impossible. I understand that "Advanced Filter" is a workaround, but it is less convenient.

In T5000#142199, @xclaesse wrote:

I am really attached to git workflow as well, so I wrote my own tool to integrate git and phabricator together:
https://phabricator.freedesktop.org/diffusion/GITPHAB/

With simple commands like "git phab attach" you can submit a git branch to review, creating one differential per commit. It is still "just" a wrapper tool on top of "arc diff", though.

I hope it can help others.

D15454 changes the wording to:

We should probably change the text on "placed up for grabs" to "unassigned from X". I don't think we use that term anywhere else nowadays, either.

This is particularly problematic in the UI when you need to revert the first change to a task since creation - there doesn't appear to be any way to find the initial assignee of https://phabricator.wikimedia.org/T129128#2105237 for example

Is the outcome of this task likely to be select a source for a given project where source might be manual, or ldap, or something custom?

Is the outcome of this task likely to be select a source for a given project where source might be manual, or ldap, or something custom?
Would it be possible for the source to not only serve as an adapter but also create/remove projects on-demand?

https://www.w3.org/TR/capability-urls/ is relevant - Good Practices for Capability URLs.

It's mainly the projects that I want to see as well. Although there has been talk of priorities etc. as well

In T10493#162973, @epriestley wrote:

It looks like the root problem in all of the downstream reports is that projects, specifically, are no longer readily available (although they previously weren't on emails deeper in the thread, either).

"implement Gmail in Phabricator"

Yeah, this was mostly-intentional while resolving T9527 / T7661.

Let me know if you hit issues -- it should just be better in every way than maniphest.query was, but I might have missed some data or something like that.

Ah, thank you. I'll update to use that.

Broadly, *.search and *.edit endpoint are replacing older *.query and *.variousnameslikeupdate endpoints, see:

It's present in maniphest.search.

I noticed today that the maniphest.points field doesn't appear in the Conduit output for e.g. maniphest.query. I can't find a task addressing this, but it would be very helpful (I have several scripts that used our auxiliary points field, but since migrating that to maniphest.points they don't work any more).