Add support for admin users

[0xdevalias]

From: #362

This would include:

• Being able to mark a user as an admin
• Having an admin panel only accessible to admin users
• Moving relevant settings from .env/elsewhere into the admin panel.

[virtadpt]

Being able to change e-mail addresses for an account would be a handy feature to have, too.

[cantino]

Agreed. If you'd like to work on this, I'm happy to offer advice and review any pull requests!

[dsander]

I will open a PR which implements parts of the feature request.

We were also thinking about moving some configuration options from .env to the database. At first we planned just to move those options that do not require a restart of Huginn, but then realized that we do not have a way to propagate the changes to all application servers, so a restart would be required for every change made. Now I am wondering how useful it would be to have the configuration in an admin panel if you still need to restart Hhuginn manually afterwards.

[cantino]

@dsander some options could presumably be stored in the DB and loaded every time they're used. A new ActiveRecord object called Setting or something. Which options were you interested in making dynamic?

[dsander]

Have to (or should) stay in .env:

APP_SECRET_TOKEN
DOMAIN
ASSET_HOST
DATABASE_ADAPTER
DATABASE_ENCODING
DATABASE_RECONNECT
DATABASE_NAME
DATABASE_POOL
DATABASE_USERNAME
DATABASE_PASSWORD
RAILS_ENV
FORCE_SSL

Require restart:

SMTP_DOMAIN
SMTP_USER_NAME
SMTP_PASSWORD
SMTP_SERVER
SMTP_PORT
SMTP_AUTHENTICATION
SMTP_ENABLE_STARTTLS_AUTO
SEND_EMAIL_IN_DEVELOPMENT
EMAIL_FROM_ADDRESS
AGENT_LOG_LENGTH
USE_EVERNOTE_SANDBOX
AWS_ACCESS_KEY_ID
AWS_ACCESS_KEY
AWS_SANDBOX
FARADAY_HTTP_BACKEND
DEFAULT_HTTP_USER_AGENT
ALLOW_JSONPATH_EVAL
ENABLE_INSECURE_AGENTS
ENABLE_SECOND_PRECISION_SCHEDULE
SCHEDULER_FREQUENCY
EVENT_EXPIRATION_CHECK
TIMEZONE
FAILED_JOBS_TO_KEEP
DELAYED_JOB_MAX_RUNTIME
DELAYED_JOB_SLEEP_DELAY

Can be changed on the fly:

INVITATION_CODE
SKIP_INVITATION_CODE
USE_GRAPHVIZ_DOT
DIAGRAM_DEFAULT_LAYOUT

TWITTER_OAUTH_KEY
TWITTER_OAUTH_SECRET
THIRTY_SEVEN_SIGNALS_OAUTH_KEY
THIRTY_SEVEN_SIGNALS_OAUTH_SECRET
GITHUB_OAUTH_KEY
GITHUB_OAUTH_SECRET
TUMBLR_OAUTH_KEY
TUMBLR_OAUTH_SECRET
DROPBOX_OAUTH_KEY
DROPBOX_OAUTH_SECRET
WUNDERLIST_OAUTH_KEY
WUNDERLIST_OAUTH_SECRET
EVERNOTE_OAUTH_KEY
EVERNOTE_OAUTH_SECRET

If we would not cache the settings we could make those that do not require a restart (are not used by the background processes) dynamic. The question I have is wouldn't the segmentation lead to confusion? I already see myself opening the .env file when I need to open the admin interface to change the setting I am looking for.

[cantino]

I'm generally a fan of 12 factor apps, so I like having stuff in the environment. Do you see a benefit of pulling some application-wide settings into the app and leaving some in the env? I definitely see a benefit for any user-specific settings, but app-wide ones seem more like .env settings to me.

[dsander]

The main beneficiaries would be docker users, if almost all configuration options would be stored in the database one would not need to recreate the container but only update the settings and restart. For some installation methods (manual install with upstart and maybe docker when the docker socket is mounted), we even could offer an automatic restart. I was excited about having the configuration accessible via a web interface once, but now I am not sure anymore if it is worth the effort.

User specific settings should be configurable via the web interface, but as of now I think we do not have any?

[cantino]

Yea, we don't have many user-specific settings at the moment, that's true.