There are two completely different flows. At HEAD, the flow is entirely different and uses none of the same code.

there's no way to change "Edit Policy" from the initial form page

Is that not the same thing as "Editable By" during repository creation?

This would work now, except that there's no way to change "Edit Policy" from the initial form page.

Nevermind I am wrong. Anyways, @epriestley can explain policies better. I think this is correct on our side.

If I set "Can Edit" to Noone and "Can Create" to Admins, I can create repositories. But this is current Phabricator.

Yea I'm really sorry about March 4th. I'll probably look at upgrading in the following weeks. I slowed down updating because of the new UI layout to differential revisions which I thought would upset some people, needed to wait for warmer weather, etc. :x)

Anyways... this sounds correct. Why should a user be able to create something they can't edit?

March 4th?

I can't reproduce this on your linked install.

@eadler Did you have enough insight/recollection as to whether all our reported cases were due to users editing in the web UI?

From a technical point of view I think the ideal solution to this is to make the commit message format unambiguously parseable, but I'm not immediately sure how to do that without making other things worse. It's valuable for messages to be human-readable and human-editable, and I think we'd be worse overall if we tried to escape or encode messages in Git itself (or represent them as XML or whatever).

I'm not sure I have a good answer to that. :/

What's the behavior you'd expect or prefer when a user writes this commit message?

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

We require reproduction steps for bug reports. I would also use an up to date version of Phabricator before filing the bug report (it's required that you update before filing a bug).

Create a custom query inside Phriction, save it, then go to Dashboards and make a Panel with that query.

looks like an awesome feature to me

Thank you we basically created two projects to group the members into those two projects and i removed myself and only stayed in one and that seemed to kind of work. I see only the files i expected but also some deleted files history that is greyed out. It would be nice to have an easy place to put custom queries to be used for each of the apps but I love Phabricator so keep up the good work thanks.

This is expected. You do not need edit permission to comment on a task or take other actions available in the action dropdown.

We should get this punted out of prototype status, don't think there is a lot to cover before that. See T11167 if you find additional items.

Isn't Badges a Prototype?

We're basically having lots of problems with Windows; There are a few reports about arc version just not working on Windows (I'm a little surprised @hach-que doesn't run into this; Can you maybe do a quick phriction page about your Windows setup, as in "this setup works, do this"?).

Your best workaround for now is multiple text panels for each organization.

T11161 is the follow up for Dashboards

I'll create a separate task to re-think Panel creation UI.

You're not creating a custom query, at least in that screenshot. The query is "All Documents", which is what you're getting.

I'm going to merge this into T9028. Specifically, daemons should be able to permanently fail operations on unreachable commits after D16131. That task discusses deleted/unreachable commits more broadly.

We can't reproduce this, so we can't move forward. Feel free to open a new issue if you are able to provide reproduction steps.

This fix appears to be holding.

Pulled and working! Thanks a lot!

This should be fixed at HEAD of master. Let us know if you're still seeing issues after updating.

Thanks for the report! This should be fixed once D16128 is reviewed, likely later today.

We have a large user base using various install locations on their PC's. The issue has come about following a recent upgrade from a 2015 version with more than one person affected.
If you look at the code I cant see why you would need write access - it is just processing path strings.
Anyway I have moved the install to your suggested directory but with no change to the fault symptom.

As someone who regularly uses Arcanist on Windows, I can't say I've seen this issue. You should try placing Arcanist in a writable directory, like C:\Tools\Arcanist. Installing it into "Program Files" is probably not ideal, as that's not a writable location.

Yeah, this is a known bug with aborting builds. It doesn't actually functionally impact anything (you can still restart the builds later, etc.)

I know you have focussed on the missing background, but I'm not overly fussed about that. But I am surprised that the commit subject shown twice in a row, once truncated inside a table and once not, is anything else but a bug.

I know I didn't retrieve all the info you asked for, so let me know if you want to see anything else or want me to decode the base64 email body.

I've learned some interesting things.

Can you provide:

Local Version Bitnami Phabricator 20160523-0

The diff UI just looks off in the video, each line takes up two lines. I don't know what browser / OS that is nor have any diffs here to reproduce it though. Retina Mac / Chrome maybe?

Is this the same issue https://slack-files.com/T029GG40X-F1FA40DUJ-cdf3ae1eec (From IRC a couple of days ago)? Extra-long words, like minified javascript, doesn't get broken.

I think this is resolved in rPd68b2cc0e4c4, but merging into the feedback/errata task regardless.

Can you try HEAD? or are you on stable?

just upgraded to the hashes from https://secure.phabricator.com/w/changelog/2016.24/ before spotting issue, unsure if it was that way before

What version of Phabricator are you running?

ah it's phutil_symbols...

I have a patch for this but arc lint is taking forever and all of my CPU... :-/

Nice! I was able to duplicate that. Might be all? dialogs.

Ah I see. So for the "create ticket" workflow, it only seems to happen when creating a ticket from a workboard. In this case, I do not see the button go disabled.

I was able to reproduce this on a Phacility test instance as well: https://test-ftzenxozitfe.phacility.com/phriction/edit/?slug=/

Does the submit button not go "disabled" when you click on it? JS should be immediately doing this. I can't not get it to do this on anything I test.

Wouldn't form re-submission be disabled through javascript on the client?

I am using Chrome on Ubuntu, but I don't think k the browser/OS has much to do with it. I'm guessing that you can't reproduce it because you have more internets than I do. If you can artificially throttle the connection speed then it might be easier to reproduce.

I can't reproduce locally or on Phacility in Chrome/Mac. Is there a specific browser/os I should test?

I did get the file to download. It think it should have just downloaded on this page though and not sent me to the File page, so I'll follow up on if that's a bug with @epriestley .

We still need a complete bug report for this. See Contributing Bug Reports.

I'll do so as soon as I can.