d'oh - thanks - I feel like at one point that wasn't yet available and must've just assumed it still wasn't.

You should be able to do "Visible To: Members of X" already (or use Spaces, even). Tags wouldn't affect visibility.

There have only been a handful of occasions where something like this would have been convenient for my team - in the "drive-by" scenario. One developer happens across a bug and fixes it locally in order to continue their testing/development, meanwhile the bug is actually part of a larger problem which another developer is investigating. The options in this scenario are:

1. Wait for "drive-by" developer's changes to be landed
2. Have the "drive-by" developer export a diff of the relevant file(s) and email to the other

Would having tags on passphrases mean that they would be usable by members of the group? I just did a check as I thought I had created a task about this previously but does not appear to be the case (maybe I was keeping it in a create form and never submitted).

I like the idea of proposing an update but not automatically applying it until the author clicks 'approve.'

Yeah, I understand, although too bad if that task is as low-pri and as large an undertaking as it seems. :/

(I think that title edit is accurate, let me know if I misunderstood.)

@asteinlein, sorry, I missed your earlier question.

Any progress on this?

It was a bug that it disappeared.

Ah. Looks like I just needed to upgrade as this change was made in the last month or so (I last upgraded late Feb). Didn't see this change mentioned in the changelog, or a task for it, so assumed it still wasn't possible. What you have implemented is perfect for us. Sorry for the noise.

This probably isn't directly related to PHP7.

See Also: T9640

Can you show me the output of this command on your system?

This was probably implemented in rP51d2d06e3722ad807be588dc894e8d0f0e8be076

In T10584#164865, @avivey wrote:

GitHub actually encourages reviewers to "Add commits to PRs"; It's a little hard to un-teach once it gets hold.

GitHub actually encourages reviewers to "Add commits to PRs"; It's a little hard to un-teach once it gets hold.

It took 6 months before I got my first patch accepted in gerrit.

In T10584#164843, @epriestley wrote:

An example of a concerning "New Hire" case is a scenario like this:

It's your first day at Big Company, Inc. as a software engineer.
You submit your first a change to fix a bug.
Someone way more senior than you rewrites it, updates over it, then tells you to commit it.

I think this is soul-crushing and incredibly toxic, and want the software to prevent this from being a path-of-least-resistance workflow as much as we reasonably can. The easiest thing should generally be to ask the author to take responsibility/ownership, fix issues, etc., -- the same thing you'd do with a more senior engineer -- so new hires are on equal footing from day one.

FWIW - full time engineers at the WMF do routinely amend each others changes in gerrit, without hesitation.

"Feature doesn't exist" or "We'd use it" isn't to us a description of a root problem. Let's say for sake of argument, we'll never build that solution into Phabricator. Can you describe what problem you are having using Phabricator and let us determine how to solve it in a way that benefits the most users.

Thank you again, I try to describe the situation more clearly.

Maybe notable is that these use cases seem to be completely different from the use cases discussed in D14104 (where "lightweight diffs are probably a plurality, if not majority"). There is also some possible overlap with T6008.

Here's a general outline of a workflow which might satisfy everything without creating the "stomp all over new hires" tension that I want to avoid:

Here's my best effort to summarize downstream use cases for this by reading through https://phabricator.wikimedia.org/T121751 -- let me know if I'm misunderstanding, missing, or misrepresenting anything:

Projects are flaggable under the manage page. We have no plans to make Workboards flaggable.

Well I have searched and the problem is windows encode names in non utf-8 code (usually Windows-1252) and commit this files names in mercurial. Then the parser extract this file names supposing the are correctly encoded in utf8 and as they aren't other classes (like commit parsers) do wrong things (for example try to insert with %s when it isn't utf).

To provide some background and context, we added Commandeer in D2257 to deal with use cases like this:

Still having the same issue although I updated to last version.

Yep, that works. I didn't realize that null was a possible return value.

Sure, so it's not the idea of consistency here that's the issue, it's which existing implementation to actually go with, and you're not convinced Maniphest's one is the way forward?

This isn't a bug, there are just no fields available.

T10579 mentions being able to query / build panels based on multiple states of a Diff or Audit.

Yeah, overall I don't think using a tokenizer universally is a good idea for statuses across Phabricator, but they make a lot of sense perhaps in a few key applications like the ones you mention. I just don't want us to make some forms harder to use/understand for the sake of consistency.

We generally don't want to be in the business of spending time debating design opinions

For Differentia/Auditl see T9372 for the task to improve search and bucketing.

Sounds like Design Feedback (see T10208) as a general task, which we generally don't accept.

EDIT: I removed my prior replies to clean up the thread and avoid anyone in the future mistaking what I wrote as anything but a simple misunderstanding.

I didn't purge the cache here, but here's an updated version of the original diff without the rendering error:

(I did half a diff on tags-on-credentials yesterday but Passphrase uses a couple of unique elements (like a "password" control) that don't currently have field support in EditEngine, so conversion wasn't entirely straightfoward.)

His reply was sent to everyone on this task (you, me, and himself).

Oh my reply was for myself because Evan beat me to a reply by a minute if you check the time stamps. Sorry for the confusion.

I wouldn't have expected the issue to be in xhpast at all. Thanks for the quick resolution!

This is made difficult by the nature of dragging cards into sorted positions on workboards: if you drag a card between a 5-point task and an 11-point task, we need to give it some number of points between 5 and 11, break the sort order of the column, or fling the card to the correct position in the column, which may be offscreen. Currently, in the simpler case of priority sorts, users don't seem to expect any of these behaviors, and all of these interactions are confusing to some users (today, we change priority).

Thanks, that test case was very helpful.

Follow-up comment not worthy of the description: I'm not sure if this should be provided for projects unconditionally, or only if the project 'uses' points (which sounds like an expensive query, or Yet Another Damn Setting™ for project owners to have to set).

In T10575#164647, @alawson wrote:

Being rude isn't a good way to attract people to a product.

Thanks for your replies. I searched pretty thoroughly for tagging and
didn't find specific examples so I didn't think it was possible to do these.

We certainly prefer consistency if possible, but I'm not opposed to being inconsistent if it's better for that individual product (ie, many installs only use Differential). But not sure the 'subheader' layout is going to be it. We'll get everything converted and live with it and see. There may be other options too, but at some point I need to move on.

I think the owner of a task is the person assigned. The owner of a revision is the author.

You know, I just noticed the way that Differential shows created date... Not suggesting a change, just offering it up as a potential place for consistency?

@rdfree50 see https://secure.phabricator.com/book/phabricator/article/support/ for what free support services are available for Phabricator. If you need direct 1 on 1 support from Phacility, we're happy to offer that as well (see https://secure.phabricator.com/w/consulting/).

Hi Evan,

i r slo

You can customize a project's sidenav with links to Pholio or Passphrase now. In the future we'll allow these links to be dashboards on the project itself.

or through Pholio