Ok i found the reason for the problem.
If you set Applications → Projects → Edit Policies → Default View Policy to Project Memebers i does not work. You can still create normal projects and subprojects but you can't create milestones. I think that is because milestones do not have members but the permissions are evaluated against the "project members".

In T5391#78626, @witrin wrote:

Problem solved:

$custom_fields = PhabricatorCustomField::getObjectFields(
        $task,
        PhabricatorCustomField::ROLE_VIEW);
$custom_fields
        ->setViewer($user)
        ->readFieldsFromStorage($task);

$custom_fields->getFields()['std:maniphest:company:field']->getValueForStorage();

This would be fully solved with T8629 so I'm just going to close it :/

This would be really nice to see, as we do post-commit code review with Audit and we semi-frequently encounter commits that have near-100% changes due to white space as someone hits an auto-formatter or changes svn:eol-style to match convention and doesn't split this out into separate commits.

This isn't a valid bug report. Please see Contributing Bug Reports and Providing Reproduction Steps.

Thanks for your message. Yes it was a server issue with Apache 2.4. Acces was denied. It's ok now.

This error for a new installation is usually do to a mis-configured webserver redirect. If you are using Apache, make sure to place the rules in httpd.conf or similar, not .htaccess.

This report does not include valid reproduction instructions. These instructions are required; see Providing Reproduction Steps for help.

If anyone else has the same problem, here is the solution. You have to edit maniphest.fields and not maniphest.custom-field-definitions.

Isn't that about editing the config to have maniphest.fields say "isdc:sprint:storypoints": { "key": "isdc:sprint:storypoints", "disabled": true } ?

Ok, then I'll investigate further and give feedback as soon as i've found something

No luck, I tried the same settings you just posted, an admin as edit policy, also in the group view and join policy. I couldn't reproduce your screenshots.

Yes I'm member of all those groups as described above. I'm also an "Admin"

I don't know the relation of your account to those policies. Are you a member of those groups?

I've posted a screenshot of my settings or do you need anything else?

Generally easier if you just tell us what your settings are that reproduce the issue, rather than us try to reverse engineer all the choices.

Yeah i did basically the same. What are the permissions of your project?

It would be handy if subprojects and milestones would inherit some of their parent's settings (like icon, color, policies, and picture) by default.

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

PHP7 is using APCu. For those in need of APC (backwards compatibility) stuff - there's https://pecl.php.net/package/apcu_bc / https://github.com/krakjoe/apcu-bc

ATM, PHP 7 is not officially supported; See T9640. Your best route forward is to use PHP 5.

c( ⁰ 〰 ⁰ )੭

(•ω•)

I requested SES limits of about 2X what we currently need and AWS gave us about 10X, so things look good so far on that front.

I did a chunk of this work as part of T10629 and we're in better shape on accepting SSL-terminated traffic now.

I've probably updated the notification server certificate, too?

T10659 discusses another complex custom rule for mapping branch names to tasks in an unusual way.

CDN stuff is maybe-sorted.

gitflow+phabricator isn't that common a combo - see https://secure.phabricator.com/phame/post/view/766/write_review_merge_publish_phabricator_review_workflow/ and https://secure.phabricator.com/book/phabflavor/article/recommendations_on_branching/ for some background.

Something on the CDN side has grown deeply unhappy, looking into it.

Seems OK. Swapping DNS shortly.

This appears to have deployed cleanly. I'm going to test notifications and SSH, and then I'll rebind DNS if they look good.

I'm going to deploy this host with rSERVICES + cluster awareness so it can accept SSL-terminated traffic. If I got something wrong, we may be down for a few minutes.

This is a little bit tricky because notifications use the same hostname, we don't have a wildcard certificate, and we can't (apparently) terminate SSL on the load balancer and pass it through with websockets.

Steps to reproduce means that we can follow what you've done and see the same error locally. Unfortunately there isn't anything here we can use to reproduce the issue. Please feel free to reopen if you can come up with the complete steps to reproduce the issue. Specifically, the steps should be repeatable and observable. For example "Every time I do X, Y, and Z, this error shows up in my log."

Sry, the relevant steps are:

• metamta.mail-adapter is PhabricatorMailImplementationPHPMailerLiteAdapter

and I got the same settings since more than a half year, (I don't know, if additional e-mail configs are required, if so, please ask) but since a short time (I don't know the exact date, but it is less than one week) there were no emails send, and the daemon throws this error (at the task description). I hope this helps.

We require reproduction steps for bug reports, please. There isn't enough information here for us to make a guess as to the root problem.

Thanks for sharing but I don't think that'll be necessary. The only place this will likely be an issue is on the config screen (and there its mostly moot).

Sorry, if that wasn't clear. "We" means just this install, not Phabricator by default.

It's not the default value, I'm sharing what ours is set to in case you want to use it.

This doesn't appear to be the default value on our install, unless you just meant its what been set here?

The upstream provider gave me a not-quite-English canned response:

Also related is T3278. There is no current means of having different flavors of Remarkup, it's all or nothing. So a "no object" Remarkup would similar to a "object only" Remarkup, and so on. For now installs just should either use a regex like above or the admins should tough it out until T3278.

We set remarkup.ignored-object-names to /^(?:(Q|V)\d|S3)$/ under Config → Core

I've issued all instances a 24-hour credit for the service disruption. This will be reflected on the next invoice you receive.

Our original upstream provider enabled the account again, also without explanation. Outbound queues are flushing now, but will take some time to completely de-queue because of backoff behavior in the queue.

In the extreme case where you have, say, a million tests, I'd expect there is probably little value in reporting each test into Harbormaster as a "pass", and your harness might want to summarize all passes into "999,998 additional tests passed" and submit two failures and one aggregate-pass.

T9704 also discusses slowness on inserting the tests. That may be unnecessarily slow right now, but I don't expect clients to submit unlimited numbers of tests in one API call. Instead, submit tests in chunks (say, of 1K tests per page or whatever) by calling harbormaster.sendmessage repeatedly with a work status.

We don't currently have a sortable column on the unit message table, since pass, fail, etc., aren't naturally sortable by any key MySQL can construct.

This is probably not a true race in the strict technical sense, I suspect you can reproduce it by doing one of these at walking speed: