In D25529#15137, @aklapper wrote:

I admit I did not test what happens when setting a (deprecated) timezone in Phorge to be removed by this patch, and then applying this patch.

Makes sense.
Fund: Going to http://phorge.localhost/fund/create/ and creating a New Initiative anyway yields

EXCEPTION: (RuntimeException) Undefined array key "totalAsCurrency" at [<arcanist>/src/error/PhutilErrorHandler.php:273]
arcanist(head=master, ref.master=6c7caf3572f4), phorge(head=master, ref.master=c0191a039293)
  #0 <#2> PhutilErrorHandler::handleError(integer, string, string, integer) called at [<phorge>/src/infrastructure/storage/lisk/PhabricatorLiskDAO.php:345]

+1 for "delete". Also Fund (which is basically a demo for Phortune).

I admit I did not test what happens when setting a (deprecated) timezone in Phorge to be removed by this patch, and then applying this patch.

I believe it was originally made for Phacility to accept donations and then process payments for paid support, neither of which we want at Phorge, and I doubt is used elsewhere. Removing seems fine to me.

Counter-diff: Keep the hackiness confined

The more I look at the code, the less I understand the comment about "just use getIsNewObject()".

In D25517#14978, @valerio.bozzolan wrote:

In an ideal world 1030-1313 could become just:

I was able to recover the layout in PNG at least. Imagine this 3''x2''. Here:

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?