I have the exact same problem, did you make it work?

Yeah, that setting is exactly what I'm getting thanks. Thanks for the info.

I think some setting like:

Thanks for the fast solution.

This is also a duplicate of T4954, which was fixed by the addition of per-linter version support in D14298.

This isn't required for our workflow but something that would simplify the implementation for us.

@chad Thanks for pointing out this obvious solution. Couldn't think of that. That of course solves my problem.

@epriestley thanks for the extra context. Makes sense now haha. Sad to see this get deprioritized though.

This was moved into the prioritization queue by a particular customer that was interested in defining Owners via Projects via external sync.

@epriestley can you explain how this was building up toward T10939? That one deals with automatically adding reviewers while this enables project membership (and hence policies) to be based on a predefined source of truth at most companies (LDAP).

You can edit the urls here: ..../diffusion/..../manage/uris/
The first .... is your domain. The second is the name of the repo.

Cool -- thanks for the report, and sorry about the issue! Some of the Diffusion/repository stuff has been a little choppy lately as we've rolled out changes in connection with T10922 / T10923. Let us know if you run into anything else.

Works like a charm. I never imagined this could be so quick ! Many thanks

If your install is not available over http, set security.require-https in Config. This will disable the http URI.

I think this was building up toward T10939, and the actual solutions we're looking at there probably don't involve this.

I think this was building up toward T10939, and the actual solutions we're looking at there probably don't involve this.

This should now be fixed in HEAD of master -- try updating again? You'll need to git pull in phabricator/ to pick up the change.

This should be fixed shortly by D15876.

The problem is that a user will not read the entire email from top to bottom. There is far too much information to do that on every email that gets sent, and most of it is essentially boiler plate.

Do you expect to continually need this function? With batch editing in Maniphest I don't see how this takes more than a minute to resolve.

I mean that it's minor to implement -- the current plan on T9372 is "don't make any major structural changes, just adjust the existing bucketing algorithm".

I'm not sure what the story behind T10283 is, since it configures a lot of options which modify how mail is laid out, but the expectation is that mail is already organized in the best order for making triaging decisions easy. But the triage flow is to read the whole mail from the beginning, top to bottom, starting with the subject and ending with a link to the object.

Reading through this discussion, it seems like we've gotten to a point where we have a reasonable simple yet general mechanism that allows us to express what we want in terms of the owners themselves.

Indeed, it's fixed ! Thanks

That could be the root of all evil. I've added the second user after importing the repository. Reparsing via "./bin/repository reparse --importing --all <REPONAME>" didn't do anything. Now I'll just reimport the repository.

@epriestley Thats good to know. Also, will this change include formatting the Change Details section of emails? That one is currently a blob of visually unparseable text even in HTML emails.

I think it's a custom select field with an explicit nonempty "None" value, so display is expected.

Security: None displaying is maybe a bug, we default don't show custom fields that do not have any value. Is this a custom field or an explicit patch?

Thank you for the explanation, @chad, very useful.

This may have been fixed by D15507. Otherwise, we can't reproduce it, so we can't move forward. See Providing Reproduction Steps.

yes, problem resolved.

For completeness, OWNERS are very briefly discussed in T8426.

Awesome! Thanks for doing all the work to figure out what was going on. I'll get a diff out to apply that fix in a slightly nicer way.

Yes, that corrects the issue!

This behavior seems reasonable at HEAD and we haven't seen other issues with it.

This report doesn't include reproduction steps so we can't move forward. See Contributing Bug Reports and Providing Reproduction Steps.

It sounds like this is resolved.

In what order did you add the second user? Before or after you imported the repository. If you did it after, you'll need to reparse

@revi This third party tool no longer exists, the two links are broken and the latest commit at https://github.com/haskell-infra/libphutil-haskell removed the changes:

Thanks for hunting that down!

I am waiting tag(s) field for credentials too.

OK, I found the issue and a fix/workaround:

I can't reproduce this: