Feature #1: Multi-tenancy

Developed by: Cabildo de Tenerife (Spain) and Consul Democracy's certified company Rock&Ror

What does it do and what can it be used for?

Non-technical functional description (max. 200 words).

The multitenancy feature allows managing several independent organizations ("tenants") or participation projects using the same Consul Democracy installation. For example, in our case, a user who signs up for one tenants's participation platform will only be able to sign in on that platform, and that user's data won't be available to any other tenant.

Which tenant we're accessing depends on the URL we're using in the browser to access the application. In Consul Democracy, the current tenant is established by the subdomain used in this URL. For example, if we used the domain participative-amsterdam.org to manage the different digital participation platforms in Amsterdam, using the URL https://south.participative-amsterdam.org we'd access data from the Southern district's participation platform while using the URL https://north.participative-amsterdam.org we'd access data from the Northern district. It's also be possible to use different domains per tenant.

Basic technical setup and what's new in terms of programming and tools used?

Technical description (max. 200 words).

Enabling multi-tenancy

There are two possible ways to enable multitenancy:

• Adding config.multitenancy = true inside the class Application < Rails::Application class in the config/application_custom.rb file

• Replacing the line multitenancy: false with multitenancy: true (or adding it if it isn't already there) in the config/secrets.yml file

The difference between these options is that the first one uses a file under version control while the second one uses a file which isn't under version control. Choose the first option if you'd like to have this change in your git repository; otherwise, use the second one. After enabling this option, restart the application.

Creating different views with Ruby variants

Sometimes it might be convenient to use completely different views for different tenants. For example, a certain tenant might use a footer that has nothing to do with the default one.

In these cases, instead of adding conditions like case Tenant.current_schema to the view, using a different file might result in code easier to maintain.

For this purpose, we can use Ruby Variants which means that, for example, a tenant named milky-way will use a view file ending with .html+milky-way.erb if it's available. That is, in order to use a different application.html.erb layout for the milky-way tenant, add a new file under app/views/custom/layouts/application.html+milky-way.erb.

More detailed technical description here

Where can I find the code's repository and user instructions, if any?

(link)

This featurs is part of the main Consul Democracy 2.0. project, available on Github: https://github.com/consuldemocracy

What does the feature look like in practice and what does the new code look like?

Visual example of live version and code (max. 3 images/screenshots)

Where and by whom was the feature developed, and how to get in touch?

Contacts (max. 50 words, Slack handle/username and/or e-mail address).

The multi-tenancy feature was developed through a collaborative project of Cabildo de Tenerife (municipality of Tenerife) and Rock&Ror.

Both parties are members of our community Slack channel.

Slack handle Rock&Ror: @Javi Martin or @sendero

E-mail Rock&Ror: [e-mail]

Slack handle Cabildo de Tenerife: @Clemente Barreto