@carlsverre, this probably impacts you, too.

Here's a rough sketchy of my thinking:

I don't plan to give mailing lists their own Email Preferences panel

(Note that this stuff isn't in HEAD yet, but will likely land today.)

T8398 has guidance on what to expect when you upgrade.

Development Log

Since this is a relatively large task that's likely to end up with a hundred thousand subtasks, I'll try to summarize progress here periodically.

@klimek, heads up about these changes since I know you're a big mailing list user, too. I'll publish guidance for installs soon (likely in the "Upgrading" section of the weekly Changelog).

"Available" means "not in a meeting", which he isn't.

I'm going to evaluate giving administrators access to the "Language" and "Email Preferences" panels if they aren't too much of a mess to implement the user/viewer split on, but I think that's all that remains here.

Is that not what this option should allow me to configure?

When the option is set we'll just bypass policies when generating mail. I'll slap a giant warning on the setting and lock it down, but I think there isn't really an alternative (other than removing it, but installs might reasonably want to choose better mailing list support over policy correctness, and the policy violation is usually not large).

(It's supposed to say "Restricted Revision" instead; there's a bug for that somewhere.)

It's in closed-source (Phacility) code, and makes the "import into phacility.com" tools aware that they shouldn't try to import mailing lists.

(If "finance department" is approximately "a single human with an existing account", you can just add them to the payment account to achieve the same effect -- but they'll have total control over the instance.)

How do you currently handle this with other services? I don't recall seeing a way to CC an arbitrary address in other SAAS products, but maybe I just haven't looked carefully enough.

I rolled this into D13122.

This basically works (projects now act as lists, approximately) but we haven't seen other use cases for it.

I currently plan to convert mailing lists into users so we can policy check mail which is sent to them. That change will largely obsolete this. I'll update the "User Roles" document to explain the new behavior.

I suppose using a logged-out viewer might be fine, since we'll use the omnipotent viewer if metamta.one-mail-per-recipient is not set, and essentially all installs that use mailing lists probably have this setting configured off.

This change is potentially going to make mailing lists useless for nonpublic installs. Our immediate options are:

Not actually meaningfully stateful:

These Editors are the only ones with state properties:

Is /config/cache/ showing significant cache fullness?

Just redirecting to the concrete ghost might be OK, too.

Awesome, thanks for testing! We'll get this upstreamed shortly.

Probably a silly question, but did you restart Apache or php-fpm after applying the patch?

At HEAD, each inline can now be individually hidden:

Tracking moves and fixes of these things seems like the hard part: it would maybe be nicer to see "all places in the codebase a task is currently mentioned", not necessarily "all places a task has ever been mentioned". But maybe this isn't actually that important.

Another (not necessarily good) attack on this would be to extract these with a linter (similar to the TODO linter), and then maybe, uh, let lint messages have an object PHID on them? I guess? This feels real sketchy but maybe there are some other reasonable things we could do which could justify it.

Can you explain what you mean in more detail? I don't know what you mean by "the report", or which application you're using, or which custom fields are working.

Pretty sure D13095 will fix this.

I think it was that phlog($ex) gives us the stack trace of the phlog() call, but if we have to pick one stack trace, the stack trace of the exception is more useful.

Do you have a full stack trace in your error log? Usually /var/log/apache2/error_log or something like that, depending on exactly which webserver/OS you're running.

Probably a prerequisite for implementing anything like arc diviner, or whatever, too. That said, it's probably also quite a lot of work.

Implementing transactions. I think that this would be messy given that (currently) no user would really ever interact with Diviner, it is always the omnipotent user.

I think that's reasonable.

See T5240.

This is working as intended. You can add the address to your account in Settings → Email Addresses if you want it to work, per the instructions in the error:

Adding the PHID: I think this is quite reasonable, since the vast majority of books have a meaningful value for the field, but it should be nullable (i.e., you should be able to generate a book from a random collection of text files on your local disk if you want) and that it's likely not the best primary organization mechanism for finding/listing books.

I removed this on purpose when making the most recent round of modularization updates. My thinking was:

Overwhelmingly, the most common reason for this error is that you have the wrong remote URI or the wrong credentials. Have you double checked that those are correct?

It's expected that this will work, as long as you're using the same address as your email address in Phabricator and as a reply address.