Any suggestions to test this on staging without mass emailing everyone / patching prod? I am trying to test this on staging with bin/mail show-outbound --id xxxx (staging has mail disabled), but the recipients / To: list look fine with or without the patch.

That's a good point about also accumulating any security notes

(There's no need for a token to get the changlog via conduit)

Asking someone who is say, 16 months behind to read 80 changelogs seems detrimental to having people keep up to date.

This is partly why I would like this -- the Upgrade / Compatibility section of changelogs is probably the only near-mandatory sections to review before upgrading (things might behave differently until you do databasey things, the way a configuration behaves has changed, etc.). My process for upgrading right now begins with reviewing the changelogs to make sure I don't miss any pre/post-intall steps, and I'd like to automate part of that if possible. For a site that's upgrading weekly this isn't a challenge, but sites that are unable to upgrade as frequently would (should?) be sifting through this stuff anyways. I think this would be part of community resources and not officially part of Phabricator.

I am however, all for making Phriction better and supportive at the CMS level for navigating / categorizing content.

I don't think there is a lot of benefit here, and worry it might actually detract someone from upgrading. We already post a changelog here, via email, and on social media. Asking someone who is say, 16 months behind to read 80 changelogs seems detrimental to having people keep up to date.

Did I really have an extra space in the title

Good job triggering the spam filter.

The workaround works, thanks!

The different edit/view policy is not the actual problem here. The problem with using spaces to solve the described scenario in an automatic fashion is that a) there is no spaces API b) the view policy for the space would also be a complex policy b.1) There is no API to create complex policies.

I going guess the here is that a small margin around the area of the hovercard is clickable? Or maybe your using a browser that displays a more nefarious issue? In Chrome/Mac I can't reproduce anything unexpected or can't find anything I'm prevented in doing, like copying text from the hovercard. Hovercards are meant to be small bits of information, and then click through to the profile. I'm not sure what "bug" there is in having a larger click area.

Why do you need separated edit/push policies if it's locked to a space with just the specific tutors and students? Is there an actual abuse case, or is this just anticipatory / hypothetical?

Ok, so root problem is more of a user story. Sorry to not getting this right. But this was my first feature request on Phabricator.

What is the bug that you're reporting here?

A root problem to us describes the issue you're trying to solve with the request, in full detail. In general we can't accept "feature doesn't exist" as a root problem. Here's an example of a root problem:

From an usability side, it would also be a possibility to create policy objects just in time, when the API user submits a transaction touching a policy:

What I would find especially useful would be a way to create named policies and then reference them when creating objects. That might warrant a separate feature-request task though.

I don't think this is related to wikimedia since we already have the functionality live in the WMF production install.

Root of the Problem: The conduit API does not provide the possibility to create custom policies. Therefore, the fine-grained policy model of phabricator cannot be used in automated workflows.

Finally I found a workaround! Conduit requests from foreign clients have to use the cURL form!
For example if I use the maniphest.edit for adding comments via powershell:

Different parts of the repository page may or may not load indicating error. I refreshed on the page with the commit a few times and sometimes it says the commit is missing and other times it can't load the content, and other times it can't load the paths, but sometimes it can load them.

I don't mean the project menu, I mean replacing the query menu on the work board with a confuigurable one like the favorites menu. I'd restrict it to task queires

I am currently using bookmarks to workaround the issue. I never considered using the project menu for the workboard views. This would certainly suffice, but it doesn't feel like the right place for it.

Ehh, that seems messy/a lot of maintenance for a single file. It'd be perfect if you could tie a paste to a file in diffusion and handle access control through the paste since that already supports policies, but I doubt upstream has any interest in that.

I think we have a basic query menu we could switch over to MenuItem, let users customize them per workboard like they can per project.

Use sub-modules and make the sub-module public? (or the parent public and the sub-module private)

Yeah, good point. I guess what I really want is "the ability to generate a static download URL with custom policy controls to a file in a diffusion". Looks like I should host this file somewhere else because I don't want the entire repo to be public.

The auth is trying to protect your code from outsiders. You can make the whole repo "public", and then there will be no auth requirement.

This doesn't quite work because the redirect to the raw version requires auth while navigating directly to the temp file appears to be publicly accessible.

Here's a (not so great) workaround:

This is for another project. If it were for KDE, I would have asked @bcooksley first.

I'll send you some kind of something-or-other for dropping "Quality" from Conduit for the moment.

@mrybczyn Is someone who is a member of the KDE Community yes, but I don't know if this task relates to stuff they do in KDE though. Based on their activity page on Phabricator i'm inclined to think this isn't KDE related but I could be wrong.

Thanks for the quick fix and the huge amount of detail under the hood, we'll give that patch a shot!

Internally, PHPMailer sends headers through two adjustment phases:

I know someone who has a normalname@domain.horse address and frequently finds services which won't accept it (since they're hard-coded for 3-letter TLDs) so I'd guess users with ={^_^}=@nekoneko.com addresses run into more frequent problems. We should handle .horse, .technology, etc., properly.

I am sure these email addresses are valid, but they are from people who run their own mailserver and can easily add a reasonable address for themselves, so I agree with your conclusion. More importantly, I want to thank you for your quick response, for phabricator, and your passion!

Can you test if this fixes the issue in your environment?

I think this is the controlling specification -- 2008 was a simpler time when no sequence of non-whitespace characters could ever be longer than 78 bytes, and a thousand bytes of memory was an untold wealth of riches:

I think the actual issue is that we're not wrapping the header. When I generate a synthetic message locally with a "To:" header with a length of ~50,000 bytes, the raw output is an unbroken line ~50,00 bytes long. I suspect this is RFC-violating and that whatever the mail gets handed to next gets upset by it.

Perfect, thanks!

The default -- PhabricatorMailImplementationPHPMailerLiteAdapter

What is metamta.mail-adapter set to?

See also T12046 for why all open source is sketchy voodoo and the eventual pathway forward here is likely replacing it with first-party code.

Two workarounds you could use here are:

(Are you associated with WMF, or just noting that they have an extension for this?)

Or maybe a better question is: @mrybczyn, are you asking on behalf of KDE, or a different project?

@bcooksley, is this another one of yours?

Thanks for catching this, and for the clear reproduction steps.

Ok, so I have several custom fields in forms such Task or New bug. Could that lead to that de-effect ?

I have no idea either. We need reproduction steps. Reinstalling will not resolve this.

There is definitely a bug here, I just have no idea what configuration of forms leads to it. @epriestley might have other guesses.

I'll wait Friday stable.... today I've switched from stable to master branch. The install is if I can say untouched and every Friday updated.
Just git pull in 3 dirs and that's all. Use well known bash script for that. All customization and setups are stored in SQL database.
What else steps to report - just pressing New task and appears that.
Is it an option to clean up folder and make clean git clone ?
If tomorrow stable don't resolve that nasty problem will proceed with clean install.

That is, the problem would be:

I guess we actually have to test this use case:

I can fix if it's one line, I just assumed it was something super hard with external urls or something.

I blame the fun police.

https://secure.phabricator.com/source/phabricator/browse/master/src/infrastructure/markup/PhabricatorMarkupEngine.php;4c7d464f8bf2627ef7455596fde2ae5667e67a57$356

Macros are disabled in Phame posts, via markup engine. This originated in D2202.

I think the way the view gets built is a little odd and I didn't get the logic quite right. Definitely a bug, thanks.

We'd want to know the root problem you're having with Phabricator specifically so that we could decide the best way to resolve the issue in the upstream. Can you go into more detail about the custom policies you're wanting to create, how often, what they do, etc?

Thanks, but we really just need the steps to reproduce the issue locally. I don't know them, I have no guesses as to how to get an installation to do that. Without knowing how to reproduce your bug specifically, we have no idea what to look for or if we're fixing the correct bug. This is a huge time burden for us, and is outside what we cover under "free support". We require every bug report to provide these steps for us, since Phabricator is a free product.

Ok, i'm an idiot.
I configured wrong endpoint.
It's working now.
Still, it might be good idea for mentioning this policy in install doc - it's not really obvious that you need

"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "arn:aws:s3:::*"

For IAM policy to work.

Probably worth mentioning that this creds are configured using IAM instead of root creds.
Policy for this user:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:ListAllMyBuckets",
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::files.example.com",
                "arn:aws:s3:::files.example.com/*"
            ]
        }
    ]
}