This behavior is not "incorrect", it just isn't the most human-readable format we could use. I'm going to merge this into T8973, which discusses this and other potential improvements to human-readability for JSON encoded for presentation.

You can award and revoke badges from conduit, though we may build a more robust award api later.

👍🏼

When I checked the source code I saw that the anchor tag was being applied
to the profile image, so I assumed that the link should be clickable only
inside the area of the profile image.

Why do you think its a bug?

Yes, I was referring to a small area around the hovercard which was clickable. Not a big issue, but just something I noticed the other day. 😄

Great, thank you!

T7413 is security/usage data.

After D17489 you should be able to do this:

Sounds reasonable to me.

Hrrm -- I can adjust bin/mail send-test to accept raw email addresses, and then you can use it to send a message to test+00001@gmail.com, test+00002@gmail.com and similar. Shouldn't be too involved.

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.