Issues like this to me (see also T11433) don't really belong in everyday documentation. The main reason being if we continually add these rare or one-time incidents to the documentation, the documentation becomes watered down, difficult to read, and likely admins will miss the more important points. We already provide Maniphest and Ponder for more alternative questions about Phabricator, which Google is good about indexing, as well as our own search engine.

I'm not sure what you could do that would really prevent this, other than changing these to real files. But as you said, it's probably not worth it. As long as users are aware of it, it could prevent these issues from popping up periodically.

Closing for lack of reproduction steps, version information, etc. Please see Contributing Bug Reports and follow our guide if you need help with Phabricator.

It's not our intention to provide detailed examples for every scenario or operating system, given the tens of thousands of possible examples needed.

Also be careful that the 'Depends on:' commit message parsing is strictly additive; if you ever change patch order in any way, your dependencies will get out of whack. If you're doing this, you can modify DifferentialTransactionEditor to reset the dependencies before parsing, but this means you throw away any dependencies manually added through the web UI.

I've added loggers in libphutil/conduit, and found out that in the differential.querydiffs requests, the conduitToken property is null.

Indeed very annoying. Updated our instance to 16.04.1 yesterday, and my day was not so happy any more. Of course this is not Phabricators fault, but I doubt that reading the Ubuntu release notes would have helped as the problem is not that obvious.

But I agree with Kevin that the point limit seems a lot less useful than the task limit. They're both useful for different reasons, but having been a scrum master and on agile teams for the past 10 years, I find the task limit more fundamental to the processes I've seen.

Cool -- I don't think we can really detect this because we don't have an opportunity to run any code to check for it. We could possibly have the web UI run a setup check, but I think we get about 1 of these a year and it's reasonably likely that users try to run bin/* before hitting the web UI anyway. If you have any ideas about how we could have caught/prevented this, let us know.

Ah, that was the case, I used sftp to transfer the data because the machine I'm trying to use it on is behind a restrictive firewall. Sorry for the confusion..

In general some kind of batching (e.g. "Donald commented on T### , approved D###, did it N other actions, click to expand") would also address this, but a view level filter seemed like an easier ask

Some sketches in M1466, but essentially we'll give you some default options, and a "navigation builder" which you can select on a per-page basis. Based on the mocks, the "hierarchy" moves to being a side navigation, and defaults now to one level. From that you can "Manage Page" and change the default for that page. Rough thinking is:

They should be symlinks. As git represents both symlinks and the executable flag, it should be unnecessary to chmod them.

If it functions identically to pylint, then you can use the same linter binding and set bin to the new executable...

ICFP2016 starts in about 6 hours:

(Possibly it might be easier to select the correct audience in Phabricator since you can use projects or other rules, but all of the use cases here and elsewhere just want to hit everyone, I think.)

Yeah, basically like the Facebook Rooster system except making it act as "pinned notifications" instead of "pinned dashboard panels". We could do either, reasonably, although it's slightly messier to do a real-time notification of "a new panel appeared on all dashboards, go look". But I'm basically not sure why this is better than email in any case where the users are employees.

I think a global banner (or some equally omnipresent, persistent element) is reasonable for "this system is going down in a couple of minutes". But if that's the only really good use case we have for it, though, I wonder if we shouldn't just build a "shutdown in X minutes" feature that automatically does this, counts down, stops new batch jobs from starting, maybe pauses builds, puts the system into read-only when the countdown finishes, etc. -- a dedicated "graceful shutdown" feature instead of just a broadcast feature. I don't think any of these things are really problems today, but I could imagine more of a "shutdown process" being useful in the future.

The "Rooster" system we had at Facebook is essentially a panel (closable) that would persist on every homepage. I would be OK forcing a panel onto all dashboards if the users can also close it. I think we need closable panels for NUX anyways. But the issue is this is still a "pull" notification, meaning the user has to visit a page to get the information. A "push" system (notification, email) is better for things like downtime. "pull" systems are good for just general FYI stuff (all-hands meeting upcoming).

To your point, we did have some users complain that even just on the primary dashboard a ticking timer was a bit distracting. But, you know, when your boss's boss's boss asks if something is feasible, you at least look into it. :) And I think countdown scenario aside, a global information display that doesn't assume the user has some specific dashboard config is potentially valuable.

@epriestley, somewhat an edict from on high, but I do think there is potentially some value in a persistent banner (a single row tall, similar to the main phab bar but perhaps even a bit skinnier.)

Yeah, agreed. I added a little discussion to T8145.

@bjshively, for this use case:

Strong preference overall to using Dashboards / Notifications. Persistent banner on all pages generally reduces employee productivity just to announce an all-hands or ice cream social, doesn't seem like the right solution.

• T11427 is similar.
• T10855 discusses a similar and possibly overlapping use case (mirroring system status into Phabricator), but I believe that use case isn't after global/on-all-pages notifications.

T8145 is also related, and maybe a little closer to intent here. I can retarget that.

I actually encouter the same problem. Setting autoclose on master only fixed it.

T11428 puts the corporate communication wheels in motion to make this change.

Update past rPa5b26104 (Jul 9).

Sorry I missed the previous notification.

Closing this since we haven't seen a response for about a week, this report didn't follow the instructions by omitting version information, and it's very likely that this is resolved by updating.

Reproduction steps are required for all bug reports. How can we reproduce the error you are seeing?

I've changed and added some translation in the Paste. In Addition you can change two config variables to have german Maniphest status and priorities :