unlike sendmail, recvmail is always optional. this is the case because
the cloudron may not receive emails at all, so app always has to be
prepared for it.
part of #804
There are two main use cases:
* A consultant/contractor/external developer is given access to just an app.
* A "service" personnel (say upstream app author) is to be given access to single app
for debugging.
Since, this is an "app admin", they are also given access to apps to be consistent with
the idea that Cloudron admin has access to all apps.
part of #791
after some more thought:
* If app moves to another location, user has to remember to move all this config
* It's not really associated with an app. It's to do with the domain info
* We can put some hints in the UI if app is missing.
part of #703
the main reason this is under app and not domain is because it let's
the user know that an app has to be installed for the whole thing to work.
part of #703
Currently, the export route only creates the snapshot (the other side
of in-place import). In the future, the export route can export to a
custom backup config (like import).
If a task fails, we can either:
* allow other task ops to be called - we cannot do this because the ops are fine-grained. for example,
a restore failure removes many things and calling set-memory or set-location in that state won't
make sense.
* provide a generic repair route - this allows one to override args and call the failed task
again. this is what we have now but has the issue that this repair function has to know about all
the other op functions. for example, for argument validation. we can do some complicated refactoring
to make it work if we want.
* just a generic total re-configure - this does not work because clone/restore/backup/datadir/uninstall/update
failure leaves the app in a state which re-configure cannot do anything about.
* allow the failed op to be called again - this seems the easiest. we just allow the route to be called again
in the error state.
* if we hit a state where even providing extra args, cannot get you out of this "error" state, we have to provide
some repair route. for example, maybe the container disappeared by some docke error. user clicks 'repair' to
recreate the container. this route does not have to take any args.
The final solution is:
* a failed task can be called again via the route. so we can resubmit any args and we get validation
* repair route just re-configures and can be called in any state to just rebuild container. re-configure is also
doing only local changes (docker, nginx)
* install/clone failures are fixed using repair route. updated manifest can be passed in.
* UI shows backup selector for restore failures
* UI shows domain selector for change location failulre
Girish Ramakrishnan