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
notifications are now system level instead of user level.
To clarify the use events/notifications/email:
* eventlog - everything that is happenning on server
* notifications - specific important events (alerts)
* email - these are really urgent things that require immediate attention. this is for
the case where an admin does not visit the dashboard often. can also be alerts like
bad backup config or reboot required which are not events per-se.
Notes on notifications
* oom - notification only
* appUpdated - notification only
* cert renewal failure - only raise when < 10 days to go. also send email thereafter (todo).
* Backup failure - only if last 5 backups failed (todo).
* Box update - notification only. we anyway send newsletter.
* box update available - we raise a notification. no email.
* app update available - we already have update indicator on dashboard. so, no notification or email.
Alerts:
* backup config
* disk space
* mail status
* reboot
* box updated
* ubuntu update required
ts is useful as a versioning mechanism (for example, icon changed). update the timestamp explicity in code instead of db.
this way health and healthTime can be updated without changing ts.
initially, i tried to put this in the current value field but that
is TEXT and has a size limit of 64K. TEXT also stores things with
character encoding, so we have to stash it as base64
We will make the percent allocation dynamic depending on the system.
When we have servers with a large amount of RAM but little swap, we
seem to use a lot of swap because of 50% allocation strategy. In such
systems, we run out of swap and thus have OOM errors even though there
is a lot of RAM available!
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
