Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple website configurations to group users and control their permissions (multitenancy) #795

Open
mconf-daileon opened this issue May 8, 2016 · 2 comments
Assignees
Milestone

Comments

@mconf-daileon
Copy link


Author Name: Leonardo Daronco (Leonardo Daronco)
Original Redmine Issue: 1804, http://dev.mconf.org/redmine/issues/1804

Original Assignee: Lucas Zawacki


Mconf-Web has one single "Site" model that stores all configurations for the website. In the fork https://github.com/mconf-rnp/mconf-web, users are also grouped in "Institutions", that have additional attributes that control the access of the users to the website. A few flags in these institutions are: force login via Shibboleth, an identifier to automatically set users with a given email format to a given institution, moderate spaces, forbid users to create spaces, and others.

The purpose of this ticket is to pull the changes in the fork and adapt them to be used with the base Mconf-Web.

There are two main use cases mapped that will use this feature:

  • Allow users to be grouped in different institutions, so that institutions can be somehow controlled (or restricted) by global administrators.
  • Allow multiple institutions or site to use the same web portal but not knowing about each other. An institution would see Mconf-Web exactly like it is today, as if the other institutions did not exist.

Considerations and ideas to implement:

  • Create a new model that will be a "subclass" of Site. This would be what an institution is today in the fork https://github.com/mconf-rnp/mconf-web.
  • Methods to get the current site (e.g. @current_site@) should return the Site with its flags already adapted according to the current user's institution.
  • Institutions include a new user role that is the institution admin. Notifications are some times sent to the global admins and some times to the institutional admins. There should be methods to abstract this.
  • If no institution is present, the application should behave exactly as it does today.
  • Institutions should not necessarily be called "institution", they could be called something else depending on how the implementation will be done.

After this feature is done, it should still be possible to use Mconf-Web exactly like it is used today and the fork https://github.com/mconf-rnp/mconf-web should also still work as it works today.

@mconf-daileon
Copy link
Author


Original Redmine Comment
Author Name: Leonardo Daronco (Leonardo Daronco)
Original Date: 2016-02-15T17:38:31Z


After discussions, we decided to use multiple sites to replace the concept of institutions. Attributes on institutions should migrate to the site, and multiple sites should be allowed.
Sites should be either isolated or "shared" (meaning they are visible to other sites).

@daronco
Copy link
Member

daronco commented May 16, 2016

See #858.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants