Skip to content
Ruby on Rails based intranet dashboard and staff directory for employees at City of Malmö
Ruby HTML CSS CoffeeScript Pascal Shell
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.
app Changed log level for SOAP. Activated auth cache May 30, 2018
bin Added Monit setup May 19, 2015
config Remove avatar May 28, 2018
db Bug fix Jan 25, 2017
lib Bug: count deleted records in LDAP sync Mar 15, 2017
puppet Version ref Dec 11, 2017
reports Added symlinked reports dir Dec 20, 2013
vendor/malmo_shared_assets Bower update Nov 24, 2014
.bowerrc Added shared assets Nov 20, 2014
.gitattributes Changed monit templates for server Feb 21, 2017
.gitignore Ignores May 28, 2018
.rspec Latest version from SVN Apr 18, 2013
.ruby-version Switched back to Ruby 2.3.3. Rails does not work with Ruby 2.4.0 Jan 24, 2017
COPYING Changed license to AGPL Apr 29, 2013
Capfile Cap deprecation warnings Jan 25, 2017
Gemfile Updated Savon May 30, 2018
Guardfile Updated Guardfile Aug 7, 2014
Rakefile Changed name of app, dropped 'Komin' Apr 29, 2013
Vagrantfile Changed name of app, dropped 'Komin' Apr 29, 2013

Intranet Dashboard

The Intranet Dashboard, “Min sida”, is City of Malmö’s personalized intranet front. News and tools on the dashboard are targeted for the employee based on roles and her own preferences. The dashboards core functionality is:

  • Targeted and user selected news from the organization and external resources.
  • Staff directory with searchable employee information with data compiled from other systems and a self service interface where the employees can update their information.
  • Direct access to tools and applications based on the user’s roles and profile.
  • User managed portrait pictures. The system acts as an avatar service for other intranet systems.

For more information about the Intranet Dashboard, contact


  • Ruby 2.3
  • Ruby on Rails 4.2
  • Nginx (for production)
  • MySQL
  • Elasticsearch 5.x
  • Memcached
  • Monit
  • LDAP or a SAML 2.0 IdP for authentication
  • LDAP directory for employee attributes
  • ImageMagick
  • PhantomJS (for testing)
  • Global Assets.

We use Puppet in standalone mode to setup development and server environments, see puppet-mcommons for in-depth details.

Development Setup

Development dependencies:

  • Vagrant
  • A Vagrant compatible virtual machine such as VirtualBox or VMWare

To get the project files and create a Vagrant box with a ready-to-use development environment on your own machine, run the following commands:

$ git clone
$ cd dashboard
$ vagrant up

Check the generated install_info.txt file in the project root for database details when the provisioning has finished.

Log in to the Vagrant box as the vagrant user and start the application in the Vagrant box:

$ vagrant ssh
$ cd /vagrant
$ rails s -b

You might need to run some of the following commands if you get errors:

$ sudo apt-get install nodejs
$ bundle exec install
$ bundle exec rake db:schema:load

Point a browser on your host system to Editing of the project files on your host system will be reflected when you hit reload in your browser.

When you run the vagrant up command for the first time it creates an Ubuntu 16.04 based Vagrant box with a ready-to-use development environment for the application. This will take some time. Vagrant will launch fast after the first run.

If you get port conflicts in your host system, change forwarded_port in the Vagrantfile You might also want to edit the value for vm.hostname and puppet.facter in the same file or do a mapping localhost mapping in your hosts host file to reflect that value.

Server Provisioning

The project contains resources for a standalone Puppet (no master) one-time provisioning setup. Do not run or re-run the provisioning on an existing server if you have made manual changes to config files generated by Puppet. It will overwrite.

On a fresh server running a base install of Ubuntu 16.04:

  1. Add app_runner as a sudo user.

  2. Log on to the server as app_runner and download the two provisioning files needed:

     $ wget
     $ wget
  3. Run the provisioning:

     $ sudo bash ./

When finished, read the generated install_info.txt file in app_runner's home directory for database details.

So, what happened?

  • Nginx, MySQL, Elasticsearch, memcached and Monit are configured and installed as services
  • A database ready for Rails migration via schema load is created (see deployment below)
  • Logrotating and database backup are configured
  • Snakeoil SSL certs are generated as placeholders
  • Ruby is compiled and managed using rbenv for the app_runner user.

The environment should now be ready for application deployment as described below.

The user app_runner must be used for all deployment task and for command executions related to the Rails application on the server. Rbenv is configured for that specific user only. The Rack application server, Unicorn, is run by app_runner.

Build and Deployment

Build and deployment is made with Capistrano 3.

In the project root, run one of the following commands including the appropriate environment name:

$ bundle exec cap staging deploy
$ bundle exec cap production deploy


Run tests before pushing code to the Git repository and before performing deployments. The application contains unit tests and high level integration/feature tests using RSpec, Capybara and PhantomJS.

Note that the test environment is named local_test due to some old Capistrano config issues.

For Ubuntu 16.04, you will need to install PhantomJS manually before running test cases:

$ cd ~/
$ wget
$ tar xvjf phantomjs-2.1.1-linux-x86_64.tar.bz2
$ sudo cp phantomjs-2.1.1-linux-x86_64/bin/phantomjs /usr/bin/
$ rm -rf phantomjs-2.1.1-linux-x86_64*
$ phantomjs -v

Run the test cases in the projects root directory in your Vagrant box:

$ bundle exec rspec

Feed Worker

The feed worker daemon updates all news feeds that are in use in the dashboard. It runs as a daemon started and monitored by Monit. The aggressiveness is defined in app_config.yml. The daemon is started/restarted by the Capistrano deployment in staging and production. To check the status, use Monit:

$ sudo monit status

Delayed Job Worker

The Delayed Job worker is started and monitored by Monit and is restarted after Capistrano deployment. To check the status, use Monit:

$ sudo monit status

Scheduled Jobs

The whenever gem is used to add database maintenance rake tasks to cron. Change the settings in schedule.rb to match your staging and production environments. Capistrano runs whenever during deployment.

LDAP Sync Worker

Syncing of LDAP attributes for all employees in the system is made with a worker and runs as a scheduled job defined in the whenever script schedule.rb.

Avatar Service

The system contains management of employee portraits and is used as an avatar service for other applications on the intranet with a REST API. If you use the Contacts API (below) you will get the URL to an employee's avatars.

Contacts API

A REST API for employees and group contacts is available.


Released under AGPL version 3.

You can’t perform that action at this time.