We want to be able to store metadata about badge awards (like who awarded a badge, when, why, a little commemorative note, etc) but currently can not because they use a very simple storage mechanism (edges). For example, see T8940.

Here's the remaining bug: when a transaction group mixes a comment and another action, badges are not shown, even though we render the profile image in large size and have space to show them. Here's a screenshot of the bug from this task:

To set expectations, this is a very low priority for the upstream. Most prior Asana/JIRA work in this vein has been for paying customers (see Prioritization).

after two users abused this to hide important tasks from developers

You can use arc alias to define some arc pull-then-feature.

This is another reason for me to dislike PHP but I really appreciate the time you've taken to explain the issue in addition to a promising fix for this task. Couldn't have asked for a better new year's gift :)

I think the fread() thing from PHP.net is just the user being clueless. He's opening a connection to an HTTP server, writing this "HTTP request":

When you have a chance, can anyone else who was hitting this update libphutil/ to rPHU5afd76 and see if it still reproduces?

I'm fairly confident that D14920 will fix this. I was able to reproduce it with the "run in a loop" method, and narrow it down from there.

But maybe my memory is poor and Workboard cards are more custom than I remember.

It shouldn't require any design, they should just work like they do in Maniphest normally, but without the board's main project. ie, if you're in Differential, and you had Differential and Mobile tagged, just show the mobile tag.

I have started to make a plugin, so far its pre aplha and its a shameless copy of the the Track plugin, so far not very useful.

Yeah, I can't reproduce it anymore either. I definitely saw it earlier today on a different install (which is up-to-date within a couple of hours) but I don't know what was special then.

This is a test.

Jwjsjs

Wjsjsjs

Sjsjdjr

I can't reproduce that. Here's what I did:

Please see Planning. Thanks!

Is there any chance this is gonna be fixed soon or is there a workaround?

If possible: display both. if not possible - many ways:

hey guys, this is my first time commit to phabricator.

:(

In T9908#148602, @joshuaspence wrote:

It doesn't seem to work properly if I try to comment and also change the status of a task. The comment appears but the task status remains unchanged.

I'm happy to send a diff over, but my design skills are quite lacking. How would.you think that the project tagd should be displayed? For example, suppose that a task is tagged with project X, Y and Z and is being viewed as a worknoard card for the board of project X. I'd say that we should show either Y or Z (as X is implied), but I'm not sure which should be preferred.

It should just be the default moving forward, I don't plan to introduce any special settings. Feel free to send a diff over if you like.

Projects displayed on workboard cards. We usually end up doing "[PROJECT] Title" as a workaround.

Probably not. What part do you need specifically, we're already building v3 projects.

Is this available for prioritization?

I think one of the issues was people making a public task, and then deciding they should change it to security, but not having the permissions to do so?

Awesome, glad to hear things sound promising. Thanks for the update!

@epriestley: We haven't pushed this to production but my initial impression from configuring forms on https://phab-01.wmflabs.org is that this should work pretty well. The only thing I haven't figured out is a way to easily transition a task between private & security sensitive and public. It seems that will require someone with adequate permissions to manually edit the task policies, which isn't the end of the world. We could possibly continue to use herald rules to make the transition easier, though I am more keen on the idea of totally killing off both the herald rules and the custom event listeners.

In T6683#86272, @epriestley wrote:

On this specific issue, we could also make the whole yellow bar a click target for "show older".

More broadly, given that this use case is extremely narrow, I wonder if we shouldn't consider a "presentation mode" -- which could maybe do things like disable notifications (particularly if we do more chat stuff later), make UI adjustments like this, possibly engage fullscreen mode, and let other users follow along (e.g., the presenter's open pages become shared, and you "follow screen" on the presenter and get the pages they open pushed to you so you can follow along locally, and maybe the pages could be saved for meeting notes or whatever, so you can go back and find stuff).

Although we don't do meetings with projections in the upstream, it's somewhat hard for me to imagine that fumbling with this link is the worst part of presenting stuff from Phabricator.

This class of use case feels wishlisty to me, but I've seen a few similar use cases (broadly, the "presentation" use case) -- for example, T4900 describes something similar. It seems like something we could eventually improve significantly on with relatively little effort.

I'm not sure how useful things like a reviewable list of "all the things we looked at in the meeting" are (and I haven't seen other software trying to build lists like this, so maybe it's not very useful) but it's the kind of thing that seems hard in the common case but easier for us given how broadly integrated we are. I could imagine this being something that doesn't exist because it's usually hard to build, but actually works really well.

In T6027#135704, @isfs wrote:

Would it perhaps be simpler if instead of developing a "Change columns" UI, actions can be added to move columns, something more along the lines of what I mocked up for T9280, i.e. a simple action with two parameters, rather than a monster action with parameters for all existing boards?:

If you want to move the task on multiple boards (which I imagine is relatively, if not absolutely rare) you would just add multiple actions. The order of the actions is clear, even if not mutable.

Ah, thanks! I thought we had one of these floating around.

Dup of https://secure.phabricator.com/T6051#75103 ?

Hm, I attempted another reproduction of the issue on a clean repo, and I can't get it to happen now either. Perhaps something didn't get the memo when I untracked some old binaries in the other repos. GA and mark this as invalid, I suppose, and I'll update here if I pinpoint a problem. Thanks anyway. :\

I can't reproduce this. Here's what I did:

Aih, I'm having one of those days.

Those reproduction instructions do not describe a bug. When you change a file and add it, it is expected that it will be part of any diffs or commits.

Hmm, okay, I wrote those out in list form to make it a bit more obvious. I don't have any way to try and duplicate that here.

Please include reproduction instructions when filing a bug report. See Contributing Bug Reports.

I agree that we should have a single wiki page set as "Project Wiki Home" or the like, set from Projects (with appropriate edit permissions), not from Phriction. Then, if someone wants a page to be "associated" with a project, but not the homepage, they simply add it beneath that main page (or link to it on the main page). That should resolve any confusion about what it means to 'associate a page'.

I have a more restricted use case, which is to proxy images from Phabricator-hosted Git repositories. For example, I'd like README.md in a repo to be able to reference images in the repo. without having to upload them as files.

This also happens on a normal arc install running on Powershell, except that I can't do any of the git_bash workarounds. I have git harnessed through Github's git shell. I'm synced with the most recent php/arcanist as of 12/30/15.

Today I`ve had some more time and investigated this issue a bit further.
I tried to debug this issue by using gdb and figured out that after a while the method DiffusionGitSSHWorkflow->waitForGitClient() in DiffusionGitUploadPackSSHWorkflow.php:35 loops forever:

[0x7f595b9d4208] stream_select(array(1)[0x3efe808], array(0)[0x3efe718], array(1)[0x40fb4c8], 1, 0) /home/build/phabricator/libphutil/src/channel/PhutilChannel.php:197
[0x7f595b9d3848] PhutilChannel::waitForActivity(array(1)[0x40fb588], array(1)[0x40fb588], array(0)[0x40fb5e8]) /home/build/phabricator/libphutil/src/channel/PhutilChannel.php:100
[0x7f595b9d3748] PhutilChannel::waitForAny(array(1)[0x40fb588]) /home/build/phabricator/phabricator/src/applications/diffusion/ssh/DiffusionGitSSHWorkflow.php:25
[0x7f595b9d34a0] DiffusionGitSSHWorkflow->waitForGitClient() /home/build/phabricator/phabricator/src/applications/diffusion/ssh/DiffusionGitUploadPackSSHWorkflow.php:35
[0x7f595b9d2ec8] DiffusionGitUploadPackSSHWorkflow->executeRepositoryOperations() /home/build/phabricator/phabricator/src/applications/diffusion/ssh/DiffusionSSHWorkflow.php:142
[0x7f595b9d28a0] DiffusionSSHWorkflow->execute(object[0x373c5c8]) /home/build/phabricator/phabricator/scripts/ssh/ssh-exec.php:267

Thanks for sharing details. I have fixed the issues.