Thanks. D17507 should fix this, and will un-stick any tasks stuck in queue.

Thanks! D17506 isn't the most elegant possible patch, but should fix this. Let us know if you're still seeing issues after that lands.

It is likely that the vulnerable code predates significant portions of the Files and permissions systems, and was just overlooked as these other systems upgraded and gained more powerful policy and permissions capabilities.

The fix is now available on master (rP7626ec0c) and stable (rP6f879559). I've upgraded this install without incident. Per above, note that upgrading destroys evidence, so you should plan any audit or response actions you want to take before upgrading.

We've started using countdowns on our dashboard as well and it's a little distracting/stressful to have that keep updating. It would be cool to have it fully customizable but the compromise plan you posted about would work well for us too.

You can adjust it if you like at https://secure.phabricator.com/source/phabricator/browse/master/src/applications/files/builtin/PhabricatorFilesComposeAvatarBuiltinFile.php;7626ec0ce10e5a9665d84622259e073744c9872d$130

This would be totally great, if our corporate username policy didn't mandate that all usernames start with the same letter 😂

That does make sense; we're using that multi-color approach for the report in the example in https://secure.phabricator.com/T12403. But we also put labels per-category, which is possible in that report because the categories are continuous over time to form ribbons, unlike this chart. For this chart, I think the mental model is that all categories are really sub-categories of the parent category "stuff we have worked on", and users only need to distinguish between high-priority and low-priority, hence the shading.

T9789 has stabilized (the majority of major transaction types now run through ModularTransactions) although it didn't end up providing much clarity here. This is no longer blocked on anything, I just need to develop a specific technical plan to resolve the "adjust" vs "expand" sequence inside transaction application so the "expand" code has access to the old text by the time it runs.

The system described in this task became "ModularTransactions", which feel like they're in a good place.

That sounds reasonable to me. We remain open to more feedback here if it does turn up, but I think we don't have a clear set of next steps otherwise. Thanks for following up!

Currently the workboard has an option for fullscreen display. However this setting is lost when the browser refreshes. Since we're using Chrome + a Chrome autorefresh extension (SuperAutoRefresh) to display a Phabricator workboard on a bigscreen TV it would be useful if this setting is persisted across refreshes. Like ?fullscreen=yes as suggested.

(D17404 is an earlier fix for a similar issue, but for self-auditors added via Herald.)

After 6 month seeing the bug, i think i've found why it does that.

To move forward, we need complete reproduction instructions which we can follow to reproduce this issue in a clean environment. See Contributing Bug Reports and Providing Reproduction Steps.

Do this man

Try as I might, I cannot reproduce this in a test instance hosted by yourselves.
The on screen description is the same (HEAD -> master), but the actual URL it goes to is different compared to my instance, even with the same repositories loaded.

@jaufrecht My pleasure. In general, using color gradients or shades is fine (and, actually, pretty much standard) for emphasizing trends. However, I would expect a use of gradients or shade of a single color to visualize a trend of a single category (topic, subject). In your case, though, the image presents trends in that fashion for multiple categories, which makes them difficult to distinguish and track. I would prefer and suggest using different colors for different categories and using a particular color's gradients or shades for each category across the time. Does it make sense to you?

I'm saying for you, not for me. Nevermind, I'm gathering that having verbal conversations isn't a priority for you guys and you don't see the value in it. No problem.

You already have all that in this public forum. We take feedback, feature requests, bug reports, have an open roadmap and design process - all for paying and non-paying customers.

@ablekh Thank you.

Allow me to clarify: as a product manager I've found it incredibly useful to talk to both current paying customers as well as prospective paying customers and users of existing free products to learn about their needs and things that work well and don't work well in the spirit of improving our products. I find that qualitative conversations like this can be very useful, sometimes more useful than quantitative and written communication.

I understand your suggestion, but taking feedback over phone is just like the worst ever for us given customers outnumber us 1,000,000 to 1 or so. It's not scalable which is why we ask people to participate here.

@jaufrecht Nice description. A quick comment on the attached image. Please take no offense, but IMHO, from the UX / usability perspective, this approach (using the same color's gradient or, in your case, shades) is pretty terrible and, as far as I know, is recommended against as the data visualization best practice. Hope this helps.

I'm not sure I understand. You want Phacility to spend development resources to understand your needs as a non-paying customer? As a thank-you?

@epriestley we're actually not, we're a SaaS users of Phabricator, self-hosted (dev.doctor.com). We are indeed free installs, but my gut is that our needs are no different than those SaaS folks that pay you. I'm offering my time as a form of thank you for what you've offered for free, though :) if you're interested in talk to large-scale customers and learning what their needs are (and even what they might pay for, as an example).

@Taskle, if you're a Phacility SAAS customer can you ping me at support@phacility.com with your instance name? I can't immediately find it. We're working to formalize the SAAS/prioritization relationship a little better, but we can push more weight behind requests if they're coming from paying customers vs free self-installs.

Here are some additional use cases and a sample implementation that is a Burn-up chart, not a Burndown chart, plus rationale.

Just wanted to chime in as a SaaS customer. :) We've been using Phab from a team of 15 to now we're about 100 people, and we use it for both our engineering teams as well as task management for our client services teams.

This also has SAAS customer interest.

In T11034#201013, @epriestley wrote:

If there's some remaining use case here, I'd also like to step back and understand it better since I suspect the best solution we can pursue is not any kind of UI change which makes it easier to find things by randomly typing guesses into the typeahead.

This got a mention in D17499, but when rendering a timeline we currently need two awards for each user who is going to get a full-sized profile image rendered.

Awesome (thanks for the super fast answer)!

My belief is that we've satisfied all the requirements for Translatewiki to move forward on their side.

Seeing the long list of merged commits here (thanks Evan and Nikerabbit for elaborating and explaining needs!), are there any further code changes in Phab needed before someone could set up a "Phabricator" project at http://translatewiki.net and let volunteers start contribute translations?

Resolved enough, unclear any benefit to installing to Favorites and Projects needs additional work to make it truly useful.

We have SAAS customer interest in this too, now.

Go to Conduit on your install.

Phrequent is a prototype application, and we don't provide support for these types of apps. Mostly it's expected that they will be incomplete and once we do move them to being officially supported they will have these features naturally (for example Conduit is "free" for any modern application.)

Is documentation available through other means than Conduit itself?

Phrequent is not installed on this server. Conduit only shows methods from installed applications.

Probably bump the version unconditionally now

(For example, if the goal was to very aggressively optimize for minimizing network traffic, we could read the entire repository history to figure out which refs were ancestors of other refs first? Then we could drop those and only ask for descendant refs. But this seems crazy, since it's saying that ~20 bytes of network traffic is more costly than like one hundred million disk I/O operations?)

it has to compare "What do I have" vs. "What do you have"