I'M REALLY SORRY FOR WHAT YOU ARE GOING TO SEE - I'M NOT A DESIGNER

No worries! I want to thank you for your enthusiasm responding to my question. I wish you a great day!

Sorry for my ping-pong. Thanks again for this question. I see you resolved. Feel free to flag as resolved.

I'm inclined to merge this. Any objections?

One concern that I have is that there isn't really a one-size fits all deployment. A single tiny VM image with the database and web server pre-installed would probably be ideal for evaluating and even for a tiny team's use. Once usage increases beyond a very basic level then users will fairly quickly outgrow a tiny VM and need at least a larger memory, more storage, possibly a separate database node, etc. Migrating from the tiny setup to a more robust setup might not be a fun process and I don't know how much we should encourage people to start out with a setup that won't scale very well for them.

I think there's an app-store style thing for hosted VMs in the big cloud providers

T15722: Phorge is inaccessible while waiting for approval after registration

Shouldn't have been. This is a support request, not a task.

Hi,
this should probably be a question in Ponder, not a task/bug report.
Bug reports require reproduction.

Welcome in Phorge and long life to FreeBSD! You are now in the family of Trusted Contributors and so you can create Tasks.

Right. I mentioned that in at least one answer. I'm closing since you resolved :)

In T15719#15280, @avivey wrote:

I'm left wondering when a "list-unsubscribe" header is appropriate - looks like anything that would need it will also need the one-click?

In T15719#15280, @avivey wrote:

This suggests to me that there isn't a third category - everything is either promotional or transactional.

I'd argue that none of our emails are "marketing" or "promotional" (or "commercial"), even if it's hard to claim they are "transactional".
But as long as 98%[1] of the users agree that our mails aren't commercial, we don't need the one-click solution.

Maybe we can wontfix this, and try other more modern approaches like flatpak. Example:

The new font family styles does look not very nice on macOS, look at the bold texts...

maybe

if ($this->getIsNewObject() || $xaction->getTransactionType == ...)

?
Then it only needs to be tested in the one case, and we can avoid code creeping from Differential here.

In D25517#14977, @valerio.bozzolan wrote:

// TODO: Once everything is on EditEngine, just use getIsNewObject()

So maybe this? but I'm not bold enough:

Before and after applying D25525:

Do all messages require one-click unsubscribe?
No. One-click unsubscribe is required only for marketing and promotional messages. Transactional messages are excluded from this requirement. ...

In T15719#15272, @avivey wrote:

1. Would adding List-Unsubscribe: https://we.phorge.it/settings/panel/emailpreferences/ header be enough to solve this?

Glad you got it working and happy to help!

This was precisely what I was looking for, thank you. Turns out auth was failing -- same UN/PW as for my mail clients, so.. ..looking into it, my MTA was accepting PLAIN auth, but not LOGIN auth. That's resolved now.

In T15719#15276, @Dzahn wrote:

@phab1004:/srv/phab/phabricator/bin# ./mail volume

Killed

In T15719#15272, @avivey wrote:

using bin/mail volume, to see if they need to worry about this. It just collects all mails created in the last N days and counts them by user.

This is promising, from the Email sender guidelines FAQ:

Re: 1), the doc makes it sound like not, but I'm not entirely sure.

1. Would adding List-Unsubscribe: https://we.phorge.it/settings/panel/emailpreferences/ header be enough to solve this?

In D25500#15024, @aklapper wrote:

and thus remove the only newly added call which returned null in src/applications/meta/query/PhabricatorApplicationApplicationTransactionQuery.php)

In D25500#15027, @aklapper wrote:

Maybe we can return ClassName::class - that is supported since PHP 5.5

there's a lot more code to update in random *Query.php classes defining getQueryApplicationClass() functions, in a separate future patch

What issues did you run into when using ./bin/mail send-test?

It makes sense thanks. Minor note:

Right. Sorry, my previous comment was very misleading!

In what case, a class can be installed "for the viewer", but generally uninstalled?

double-accept

Sorry for the confusion. I mean that the /mail/ page is the Mail Dashboard that allows to see both Inbox and Outbox (visible from the left sidebar menu). For example this is the exact Outbox sub-page:

Maybe we can return ClassName::class - that is supported since PHP 5.5

Note to myself: Makes sense; there's a lot more code to update in random *Query.php classes defining getQueryApplicationClass() functions, in a separate future patch

Revert turning getQueryApplicationClass() abstract in the parent class src/applications/transactions/query/PhabricatorApplicationTransactionQuery.php and make it return null again (and thus remove the only newly added call which returned null in src/applications/meta/query/PhabricatorApplicationApplicationTransactionQuery.php); also return ::class as proposed by Valerio

Fix D25501#14443: Do not show an "Query overheated" error when the user is anonymous and the application has been uninstalled

Once I get back to working with that instance, I suppose I'll go to my inbox -- where (you seem to be implying) it will show me errors from when the system sent me the initial authentication email? That seems like an odd location, but ok.

Indeed :)

That sends me to my inbox here -- do you mean, on my own instance?

Nice trick for you: to register a new identity try adding +something after your email username. Example: smith+test1@example.com. That is a secret feature of mailboxes.

Have you already seen this page? maybe useful?

In D25501#14458, @20after4 wrote:

Are there any feed transactions that are visible to logged out users?

Also, the authorization process is rate-limited to 3 emails per hour, preventing me from using that to send an additional test email that way

Play it safe by using phutil_nonempty_scalar() and do not assume that integers are actually integers (because "1" and such)

• Update Map

• Increase line height