Our current setup had a mailbox allocated for an app during app
install (into the mailboxes table). This has many issues:
* When set to a custom mailbox location, there was no way to access
this mailbox even via IMAP. Even when using app credentials, we
cannot use IMAP since the ldap logic was testing on the addon type
(most of our apps only use sendmail addon and thus cannot recvmail).
* The mailboxes table was being used to add hidden 'app' type entries.
This made it very hard for the user to understand why a mailbox conflicts.
For example, if you set an app to use custom mailbox 'blog', this is
hidden from all views.
The solution is to let an app send email as whatever mailbox name is
allocated to it (which we now track in the apps table. the default is in the
db already so that REST response contains it). When not using
Cloudron email, it will just send mail as that mailbox and the auth
checks the "app password" in the addons table. Any replies to that
mailbox will end up in the domain's mail server (not our problem).
When using cloudron email, the app can send mail like above. Any responses
will not end anywhere and bounce since there is no 'mailbox'. This is the
expected behavior. If user wants to access this mailbox name, he can
create a concrete mailbox and set himself as owner OR set this as
an alias.
For apps using the recvmail addon, the workflow is to actually create
a mailbox at some point. Currently, we have no UI for this 'flow'.
It's fine because we have only meemo using it.
Intuitive much!
Add a table and the install/configure routes. Initially, I thought
we can just keep the env vars in docker container but that doesn't
work since we create the container only later in apptask. And if the
container gets deleted we lose this information.
we have to track the members of a list in the mail app separately
from groups. this is required because users can now have multiple
mailboxes. and because of that we cannot do a 1-1 mapping of group
members to mailboxes anymore. the ui is changed to select mailboxes
when creating a list.
This adds domains table and adjusts the apps and mailboxes table accordingly
Also ensure we explicitly set the table collation, this is required
for the foreign key from apps table (utf8) and the newly created
domains table, which by default now would be utf8mb4
Put db table constraint for mailboxes.domain
Update the schema file
App backup can take a long time or possibly not work at all. For such
cases, do not stop the app or leave it in some errored state.
newConfigJson is the new config to be updated to. This ensures that
the db has correct app info during the update.
* Install in subdomain 'test'
* Move to subdomain 'test2'
* Move to another existing subdomain 'www' (this should be detected as conflict)
* Move to subdomain 'www2' (this should not remove 'www'). This is why dnsRecordId exists.
We already store JSON blobs there and the gce dns backend
will require a larger blob for a certificate.
Since we use innodb the storage format in TEXT will only be different
if the data is large
