Somewhat related to type-ahead:

Is there a task open that will move archived projects to the end of the type-ahead list?

This isn't a use case we're interested in supporting. Phabricator creates the repository in a well-defined location, not a random location.

I was adding a new repo to Phabricator. By default Phabricator creates the repo in a random location. I wanted to make the new repo follow the convention of all our other repos.

In T11112#179360, @eadler wrote:

Not only this, but multiple Herald rules can conflict.

In T11112#179356, @epriestley wrote:

(...) I think these are fairly self-evident (...)

Yeah; I have a few times implemented a type-ahead system in the past where the already-present options are shown at the bottom to allow better accessibility for moving tags around in the list (e.g. for people that can't drag things), so that might be a better solution anyway.

That isn't a usable root problem description, you've just restated the original feature request.

I was trying to do something that I have done several times before (change the storage location of a mercurial repo).
Up until today i always first attempted to do so by editing the repo in the GUI. The GUI up until today always told me "run such and such a command". This is no longer the case. I had to figure out the command myself.

This creates a problem for absent-minded or new users:

When filing a feature request, we need you to describe your root problem, not just ask for a feature. See Describing Root Problems for help.

Not only this, but multiple Herald rules can conflict.

I think I figured this one out: it's actually because more than 100 rooms are being filtered. The (`id` < 367) part is being added by pagination code, but won't activate if a user is in less than 100 rooms.

We should fix these, but I think these are fairly self-evident and I think fixing them isn't trivial since I recall declining to fix them the last time I was in this code.

My device is part of my life based in a real timezone. My OSS development and other intensive online community activity occurs in UTC, to simplify my mental calculations about other people's current time and aiding communication of timestamps and deltas.

Can reproduce in v 47.0

I tested on 4.4.2 and it worked.

I'm not sure I understand the use case for that. Do you set your client OS to local time, but prefer to use Phabricator in UTC? Offhand, this seems unusual. Do you have any particular reason for doing this (e.g., you live right next to a timezone boundary and change zones multiple times per day)?

Could we special case UTC, with a custom message and simpler "no change" process?

I added you to Community, so you should be able to make edits yourself now

Because they waste people's time being looked at forever.

Yes, but why?

Can we move tasks like this out of real projects? To a junk project?

Specifically, you saw this page, and decided that you were not in the right place?

(Low priority IMO.)

Was there any indication that the form wasn't working / wouldn't have worked?

Hi,
Thanks for responding. I was evaluating phabricator on my Ubuntu machine. I was certain the UI user registration wont work because email wont be sent out. So I went to terminal and used ./accountadmin to create an admin user.

This is solved with D11688, but it needs to be turned on globally (at the moment it's a per call option, which was added so that internally our custom unit test runner wouldn't deadlock).

This should be resolved at HEAD of master. To get it to work you may need to update and then go through the password reset process again.

I'm sure there are still some cases where we don't do a particularly good job, but let me know when you run into them.

In T7643#179137, @epriestley wrote:

Diffs should be less choppy now, here's the improved version of the above change:

In T6916#179233, @epriestley wrote:

I have no idea if this is MP4 or not:

IMG_0370.MOV0 BDownload

I think this one works:

I have no idea if this is MP4 or not:

I think maybe there is a bug here also though with EditEngine. @epriestley ?

./bin/auth

Yes - that definitely makes sense. Thanks!

At least with Flags you can still review it after landing and raise any concerns.

Yeah unfortunately we don't have not rules for queries, just not much interest. Herald can be used to auto-flag like you suggest. It's not a perfect solution for what you want, but I think gets most of it in an absolute way. My main concern about just using a query is some sort of race condition where your sent a review, it's reviewed and landed while you're out in a meeting.

bin/auth recover is a general-purpose flow not specific to this case.

I've never needed to recover an account. Can you give us details about how you ended up in a place where you felt that was necessary?

I faced the same issue too. As a user, after setting up a web UI why go back to terminal and type

./bin/auth recover <username>

and then come back to web UI to login? Once the setup is completed, a user would feel that the job is done and now he can login in peace.

I saw this today, we just created a new panel

I'm going to merge this into T6916. That implements a reasonable behavior for application/ogg (assume video by default, allow users to embed as audio instead with media="audio") and browser seem to do fine when audio is embedded with <video /> anyway, so I suspect we'll be in reasonable shape after that and not need to try to determine the contents of OGG containers in a more sophisticated way.

I've re-created 2 sub-cases of "arc patch with binary files":

1. deleting files with --skip-binaries D15972: When removing large binary files, specifying --skip-binaries, the patch fails
2. rename + move D16070: When git detects a file as "renamed and moved", the patch fails. If the modification is huge, it's considered "delete and add", which does work.

Thanks for the suggestion! I tried the search you suggested, but I think that pulls up both revisions that I've accepted and revisions that I haven't yet accepted.

Overall though this feels arbitrary if you need to be performing reviews. That is, it's not really consistent or programatic that you'll catch something. Prefer using owners/herald/blocking reviewers to enforce better review policy.

I would "Flag for Later" the review then if this is an individual desire or create a new search with something like "Reviewer = me and status = accepted"

Not exactly - we tend to list multiple reviewers on changes, but we don't formally require multiple reviewers to accept before landing changes.