currently phabricator is POC on our team, if the company would like it they would purchase it. currently we don't have any budget for POCs at all.
The only thing I can do right now is look into the code and fix it (contribute code).

In T11367#187111, @hach-que wrote:

Users don't have anything to do with Phragment? Unless I'm misunderstanding something?

In T8298#187116, @davidhodeffi wrote:

can you please raise the severity for this issue ? It is really hard to work like that
when renaming a file 'svn mv'. for now we are just committing the code and using an Audit.

can you please raise the severity for this issue ? It is really hard to work like that
when renaming a file 'svn mv'. for now we are just committing the code and using an Audit.

@epriestley I was trying to recreate my problem I had a month ago and write a task (bug report) for it and wasn't able to reproduce the issue of Drydock trying to allocate resources indefinitely. Have you already added a timeout to Drydock leases?

Users don't have anything to do with Phragment? Unless I'm misunderstanding something?

Any estimation how long can this be fixed? If it takes long, I will break the parent/subproject relationship. Otherwise I can just wait for the fix.

In T11367#187106, @hach-que wrote:

Phragment is super out of date and FYI, hasn't seen any usage from me for a while. I don't know if anyone else is using it, but you can probably feel free to just delete the whole thing since it's a prototype anyway.

Phragment is super out of date and FYI, hasn't seen any usage from me for a while. I don't know if anyone else is using it, but you can probably feel free to just delete the whole thing since it's a prototype anyway.

@epriestley When merging task which is clearly speaking about something else (although related), please update the task title and description to contain the data from merged task so they won't get lost. Thank you.

I understand a high level problem of "i get too much mail when watching a project", but I don't really have a picture of the specific "root problem". We don't really want to guess why a specific column is more interesting. Knowing the background of the project and columns might provide some insight. Maybe they need to "sign off" for instance in anything that comes into a specific column, like "QA". We just don't know, so it's hard to understand what the correct upstream solution is without these details.

I don't have any idea where further/deeper to go than to what I already described in the description:
User is not interested in being notified about all tasks of the given tag, but only on those which are in particular column.
If you ask "why", I can imagine perhaps "I don't want to be spammed by things I am not interested at".
Perhaps might yet be worth to note, that it obviously applies to boards sorted by categories/area, not progress-wise (Kanban).
I can also assume it is related to discouraging of "tracking tasks" (ie. due to many issues with task graphs) which are typically exactly equal to such workboard column - they "monitor" certain area of the project, so user is subscribed to them, but not watching the entire project.
I don't know what to add more. Better if you ask.

You should see this information about the feature request form:

@Danny_B Are you aware we don't take feature requests that omit root problems?

I ran into the same issue and phabricator-ssh-hook.sh and its parent directory are owned by root and the script have 755 mode. The script was in /root/phabricator/ and vcs-user doesn't have access to that directory (because the /root directory is not accessible). I put the script in /etc/phabricator and it worked.

Here's an effort to collect use cases for the hooks I plan to break or replace:

Concretely, I think this breaks down as a mixture of modernizations and new code:

Changes connected to T8116 implement the initial server-side version of this. It's still very skeletal, but we probably need to make some client changes to move forward. In particular, the next object to implement is probably Signature, but signature algorithms should live in the client since the client will need to be able to verify signatures.

I'm just going to consolidate this into T5055, I think they're pretty much the same task at this point.

I wasn't really sure. So I thought that "previous commit to build [...]" and "ancestors of that commit [...]" relates to the order in which Herald triggers, which must not be equal to the one in the repository. So Herald would trigger B-A-C and the build step Wait for Previous Commits to Build just ensures that they are processed sequentially. But regarding to your comment this was obviously a twisted thought of mine. :D

Given my description, what other behavior do you think it might have?

Thank you very much for your fast answer! What about the order? Does Herald/Harbormaster ensure in this case that the builds are always processed/triggered in the right order? I mean if there are three new commits A-B-C in branch develop pushed, is A build before B is build before C?

If you have the ability to edit a diff, you have the ability to edit a diff and it's relationships. That seems the simplest, most straightforward way to describe the way permissions work here.

I expect, that I can a) don't add commits etc, no matter, if I press the button at the task nor at the commit for example, or b) I can do it at both ways.

(T11357 is a companion issue for Files.)

D16323 uses <input type="text" pattern="\d*" />, which appears to have the best behavior.

On iOS 9.2 in the simulator, <input type="number" /> gives you this keyboard:

Oh, there's a "Toggle Software Keyboard" option that I somehow disabled.

On iPhone Simulator, the behavior of <input type="number" /> appears to be "draw the keyboard for 1 frame and then immediately hide it".

Looks like an iPhone with Gboard keyboard.

Offhand, do you know if <input type="number" /> has the desired behavior on your device?

In broad terms, well, you've got a good product and vibe going on and I guess I'm not the only one asking myself "when will phab have feature x and be able to do feature y". Being more transparent in that way could help better promote phab and even win more users over just by seeing what you're up to. It's easy to get addicted to your progress and to see exciting new stuff regularly.

I've not looked into the details of the implementation you started, but because it's gettext I thought maybe some links wouldn't harm:

• https://blogs.gnome.org/mclasen/2016/07/21/using-modern-gettext/
• http://nedohodnik.net/gettextbis/
• http://laxstrom.name/blag/2013/11/20/review-of-gettext-pot-file-format/

What behavior do you expect?

@epriestley Why? Actually I think this is confusing.

I would like to add, to anyone browsing this and trying to get a new instance of phabricator working on php7, to not do that (since it isn't supported and is now blocked by the software itself).

I recognize as a user (and a developer myself) the situation and that, as a user, I'm just complaining and not giving solutions. I also recognize you don't want to be dual-developing phabricator on multiple fronts. We're running on arch so I'm extremely biased AND recognize that saying this isn't a workable solution but because of the "bleeding edge" php levels on arch, I would prefer focus on php7 (again, super biased and I know that isn't just going to happen).

What would you like us to do differently?

I think what is most frustrating about this is, having fought through php 7 configuration (without opening tickets, just trying to follow other tickets and doc), after an update today I'm greeted with having to edit source now to get php 7 (unsupported, I know) to continue working...

This is working as intended.

Did you run into this on a local install or this install?

Thanks :).

File a bug report please.

It didn't work for me.

Isn't this more or less the same issue as arc set-config needs to update either local or global configs?

In T11364#186934, @epriestley wrote:

Specifically, I'd like to understand what concrete pathway led you to encounter this. A list of hypothetical situations isn't useful in anticipating or recovering from broader problems.

Specifically, I'd like to understand what concrete pathway led you to encounter this. A list of hypothetical situations isn't useful in anticipating or recovering from broader problems.

@epriestley Because it allows the reader of this report to reproduce the underlying issue without cloning anything or clobbering their .arcrc. Here are some less contrived scenarios, which are not mutually exclusive:

• the user makes a typo (project lacking .arcconfig, or trying to use Phabricator for the first time themselves)
• the .arcconfig comes from a time before Let's Encrypt (e.g. if you're in the middle of a git bisect that takes you back some distance)
• the admin is just attempting to migrate people to more secure services and does not expect that services will fail (or at least not fail in such an opaque and confusing manner) in the face of a redirect

This looks closer to a server configuration issue to me and is actually a pretty strange behavior (mostly because i'm not sure how the redirect after it looks like a request is served works). If I go to http://secure.phabricator.com/api/user.whoami in the browser i get the following

{
result: null,
error_code: "ERR-CONDUIT-CORE",
error_info: "You are trying to save some data to Phabricator, but the request your browser made included an incorrect token. Reload the page and try again. You may need to clear your cookies. This was a Web request. This request had no CSRF token."
}

as expected or maybe not? However if i run curl http://secure.phabricator.com/api/user.whoami i get

{"result":null,"error_code":"ERR-INVALID-SESSION","error_info":"Session key is not present."}

Why are you running arc install-certificate with a manually entered URL?