We hit this interesting case:
1. Dashboard showed update indicator for an app of v1. indicator is saying v2 is available.
2. In the meantime, the cron updated the app from v1 to v2 and then to v3 (i.e updates applied)
3. Dashboard for whatever reason (internet issues/laptop suspend) continues to show v2 update indicator.
This is despite the update logic clearing the update available notification.
4. Use clicked updated indicator on the updated app. App updates to an old version v2!
the DNS backends require many different params, it's just easier to
pass them all together and have backends do whatever.
For example, route53 API requires the fqdn. Some other backends require just the
"part" to insert.
* location - location in the database (where app is installed)
* zoneName - the dns zone name
* domain - domain in the database (where apps are installed into)
* name/getName() - this returns the name to insert in the DNS based on zoneName/location
* fqdn - the fully resolved location in zoneName
verifyDnsConfig also takes a domain object even if it's not in db just so that we can
test even existing domain objects, if required. The IP param is removed since it's not
required.
for caas, we also don't need the fqdn hack in dnsConfig anymore
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.
This allows one to easily add "dev.staging@domain.com" etc without having to create
yet another domain. This plays well with the concept that we have a
mail domain for every domain. So we get mails from @domain.com working for
these subdomain installations.
