Moodle
  1. Moodle
  2. MDL-28946

Add support for multi-tenancy sites

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Blocker Blocker
    • Resolution: Unresolved
    • Affects Version/s: 2.1
    • Fix Version/s: DEV backlog
    • Component/s: Administration
    • Labels:
    • Affected Branches:
      MOODLE_21_STABLE
    • Rank:
      18493

      Description

      Multi-tenancy is the ability to have multiple virtual Moodle sites running on one copy of Moodle.

      Example use case: A commercial training company create Moodle courses and wants to sell training services to multiple customers (eg companies). They do not want to run a whole Moodle for every customer because they want easy management and reporting, yet they also don't want users from one customer seeing users from another.

      Each customer can manage their own users, as well as having a custom frontpage and a custom theme, enabling them to have what seems like a whole Moodle site each.

      Originally this was part of the cohort plans (see http://docs.moodle.org/dev/Site-wide_groups) but was never implemented as part of that.

        Issue Links

          Activity

          Hide
          Martin Dougiamas added a comment -

          Petr has been developing a spec that introduces a new "Tenant" concept and a new level of contexts.

          https://github.com/skodak/moodle/wiki/Multitenant

          Show
          Martin Dougiamas added a comment - Petr has been developing a spec that introduces a new "Tenant" concept and a new level of contexts. https://github.com/skodak/moodle/wiki/Multitenant
          Hide
          Juan Leyva added a comment -

          Hello,

          What about contrib plugins?
          Plugins for 2. may return unexpectd results
          For example> the block that list all the courses in a collapsable tree will stop working if the campus is using tenants with their own courses

          The approach looks promising but I think that adding tenantid to the config table (or creating a tenant_config table that overrides config) will be your feature request Number 1.
          It will be very interesting if an administrator of a tenant can change the tenant configuration.
          I know this is quite complicated because there are a lot of configurations not suitable for tenants but a small subset I think will be necesary.

          Something like that>

          $temp->add(new admin_setting_configtext('locale', get_string('localetext', 'admin'), get_string('configlocale', 'admin'), '', PARAM_FILE, $suitablefortenants));

          Show
          Juan Leyva added a comment - Hello, What about contrib plugins? Plugins for 2. may return unexpectd results For example> the block that list all the courses in a collapsable tree will stop working if the campus is using tenants with their own courses The approach looks promising but I think that adding tenantid to the config table (or creating a tenant_config table that overrides config) will be your feature request Number 1. It will be very interesting if an administrator of a tenant can change the tenant configuration. I know this is quite complicated because there are a lot of configurations not suitable for tenants but a small subset I think will be necesary. Something like that> $temp->add(new admin_setting_configtext('locale', get_string('localetext', 'admin'), get_string('configlocale', 'admin'), '', PARAM_FILE, $suitablefortenants));
          Hide
          Petr Škoda added a comment -

          Hello, if you need separate configs you have to use separate sites, it is technically not possible to have separate global settings. Either it is a global setting for everybody or a context dependant settings, there is no other way, sorry.

          Show
          Petr Škoda added a comment - Hello, if you need separate configs you have to use separate sites, it is technically not possible to have separate global settings. Either it is a global setting for everybody or a context dependant settings, there is no other way, sorry.
          Hide
          Ray Lawrence added a comment -

          My view on this would be that a decision needs to be taken about which config settings a that are currently global i.e. all tenants, can be effectively be delegated down to tenant "admins".

          Navigation block is global atm. This needs to be configurable at tenant level.
          Category, course, user themes.
          Messaging

          The above are some quick examples that come to mind.

          This is less of an issue where the tenants are, say, depts in a company. More so where tenants are clients.

          Clearly there will need to be an element of compromise on a single site/multi tenant set up. The challenge is to ensure the site is not a nightmare to administer but there are sufficient opportunities to differentiate at tenant level for this to be useful.

          Show
          Ray Lawrence added a comment - My view on this would be that a decision needs to be taken about which config settings a that are currently global i.e. all tenants, can be effectively be delegated down to tenant "admins". Navigation block is global atm. This needs to be configurable at tenant level. Category, course, user themes. Messaging The above are some quick examples that come to mind. This is less of an issue where the tenants are, say, depts in a company. More so where tenants are clients. Clearly there will need to be an element of compromise on a single site/multi tenant set up. The challenge is to ensure the site is not a nightmare to administer but there are sufficient opportunities to differentiate at tenant level for this to be useful.
          Hide
          Ray Lawrence added a comment -

          "Each tenant is expected to be an entity completely separate from the rest of tenants, this is not intended to be used for logical splitting of one organisation."

          Petr, what does that mean? Is is that this will not implement a hierarchical approach to managing/organising users i.e. Company, division, Branch, Team etc.?

          Show
          Ray Lawrence added a comment - "Each tenant is expected to be an entity completely separate from the rest of tenants, this is not intended to be used for logical splitting of one organisation." Petr, what does that mean? Is is that this will not implement a hierarchical approach to managing/organising users i.e. Company, division, Branch, Team etc.?
          Hide
          Ray Lawrence added a comment -

          "The email does not have to be unique because we do not use it as an identifier, the only trouble is password resetting. I think I have found a solution: if you find multiple accounts with the same email address we can add extra password reset step email - ask user to choose which account to reset. This should be simple and 100% reliable."

          Great!! When can we have this?? This would solve many issues with current Moodle installations.

          Show
          Ray Lawrence added a comment - "The email does not have to be unique because we do not use it as an identifier, the only trouble is password resetting. I think I have found a solution: if you find multiple accounts with the same email address we can add extra password reset step email - ask user to choose which account to reset. This should be simple and 100% reliable." Great!! When can we have this?? This would solve many issues with current Moodle installations.
          Hide
          Ray Lawrence added a comment -

          "No changes expected, we should not mess with the user table and auth plugins at this point because tenants are expected to be small."

          I can't agree with this. This is an assumption that will not be borne out in practice IMO. Clients will expect that tenants can be of any size subject to the normal considerations e.g. memory, storage, CPU etc.

          Show
          Ray Lawrence added a comment - "No changes expected, we should not mess with the user table and auth plugins at this point because tenants are expected to be small ." I can't agree with this. This is an assumption that will not be borne out in practice IMO. Clients will expect that tenants can be of any size subject to the normal considerations e.g. memory, storage, CPU etc.
          Hide
          Ray Lawrence added a comment - - edited

          "Enrol
          Difficulty: easy
          Course level enrol is going to work fine, the only change is that the enrol will allow enrolment from the current tenant of global users. LDAP and external DB will not be configurable from inside the tenant sites."

          Not great in this early spec. Say, site 10,000 users, 5 tenants 2,000 each. Manual enrolments in courses is not a credible solution for that user population, especially where the user data is held elsewhere.

          A tenant specific upload might suffice.

          Edit: I was working through these an item at a time, just got to the upload item.

          Show
          Ray Lawrence added a comment - - edited "Enrol Difficulty: easy Course level enrol is going to work fine, the only change is that the enrol will allow enrolment from the current tenant of global users. LDAP and external DB will not be configurable from inside the tenant sites." Not great in this early spec. Say, site 10,000 users, 5 tenants 2,000 each. Manual enrolments in courses is not a credible solution for that user population, especially where the user data is held elsewhere. A tenant specific upload might suffice. Edit: I was working through these an item at a time, just got to the upload item.
          Hide
          Ray Lawrence added a comment -

          " It is not possible to migrate standard course to tenant course or category, or the opposite direction."

          Agree. Need to be firm on this, it will be one of the compromises.

          Show
          Ray Lawrence added a comment - " It is not possible to migrate standard course to tenant course or category, or the opposite direction." Agree. Need to be firm on this, it will be one of the compromises.
          Hide
          Ray Lawrence added a comment -

          Blogs: add tenantid to blocks - tricky to separate these, it could probably work with different tenant domains only, better than disable.

          Show
          Ray Lawrence added a comment - Blogs: add tenantid to blocks - tricky to separate these, it could probably work with different tenant domains only, better than disable.
          Hide
          Ray Lawrence added a comment -

          FAQS: All seem sensible to me.

          Show
          Ray Lawrence added a comment - FAQS: All seem sensible to me.
          Hide
          Vijay Nair added a comment -

          Hi All,

          I am quite interested in having this feature in Moodle and so am going to share a few insights into what the moodle portal would hopefully look like based on a current set up by commercial LMS system. There would be a "global Moodle install" and then instances of moodle installed from within the global moodle. Here are the steps which I wish to see in the global Moodle install.

          1) With the Global Moodle install, you can create customised Moodle instances and define which theme to use and set up an Administrator on this moodle portal (the Administrator of this moodle instance will be shown only on Global moodle and not the moodle instance - this is required so that clients donot delete this administrator account on thier moodle portal/ instance). Setup system/email notifications to send emails to the moodle instances.

          2) Once the Moodle instance has been created from the global Moodle, then you login to Moodle instance using the Administrator account that you created in the global moodle set up and configure it to your client requirements (meaning setting up the courses/activities/resources/ roles/permissions just like how you would in a normal moodle instance). There should also be a way to manage all there moodle instances and their respective Admin accounts/role

          3) If you would like to install additional/contributed plugins on the moodle instances. There would be 2 approaches:
          a) Install it from within the Global set up so that every one gets it
          b) Using some sort of web interface for installing it on each moodle instance. - again not sure how its done but sharing thoughts here.

          4) Ability to enable/disable moodle instances (hide/lock)
          5) Ability to lock certain features(categories,courses,activities, etc...) directly from Global setup in order to control what features are available in each moodle instance.

          I have added just added some of the many things that can be looked by the developers for creating this type of moodle environment.

          V.

          Show
          Vijay Nair added a comment - Hi All, I am quite interested in having this feature in Moodle and so am going to share a few insights into what the moodle portal would hopefully look like based on a current set up by commercial LMS system. There would be a "global Moodle install" and then instances of moodle installed from within the global moodle. Here are the steps which I wish to see in the global Moodle install. 1) With the Global Moodle install, you can create customised Moodle instances and define which theme to use and set up an Administrator on this moodle portal (the Administrator of this moodle instance will be shown only on Global moodle and not the moodle instance - this is required so that clients donot delete this administrator account on thier moodle portal/ instance). Setup system/email notifications to send emails to the moodle instances. 2) Once the Moodle instance has been created from the global Moodle, then you login to Moodle instance using the Administrator account that you created in the global moodle set up and configure it to your client requirements (meaning setting up the courses/activities/resources/ roles/permissions just like how you would in a normal moodle instance). There should also be a way to manage all there moodle instances and their respective Admin accounts/role 3) If you would like to install additional/contributed plugins on the moodle instances. There would be 2 approaches: a) Install it from within the Global set up so that every one gets it b) Using some sort of web interface for installing it on each moodle instance. - again not sure how its done but sharing thoughts here. 4) Ability to enable/disable moodle instances (hide/lock) 5) Ability to lock certain features(categories,courses,activities, etc...) directly from Global setup in order to control what features are available in each moodle instance. I have added just added some of the many things that can be looked by the developers for creating this type of moodle environment. V.
          Hide
          Petr Škoda added a comment -

          Hello Vilay,

          non from your 1-5 points would be satisfied by the proposed multitenant design. It seems you are requesting complete separation of instances, this is already possible - all you need is to write some simple tool that does provisioning on your server, maybe some existing webhosting infrastructure solution would be suitable for you.

          The linked multitenant proposal has several strict limitations:
          1/ independent tenants - no branches or divisions of one company (use mnet or other SSO solution, moodle does not scale anyway for large sites)
          2/ standard admin settings would not be available in the tenant site (there are no admins the tenants, only standard manager roles)
          3/ all sites have the same plugins installed (later we could add some hacks for hiding of plugins in each tenant or even course categories)

          Thanks for the feedback!

          Show
          Petr Škoda added a comment - Hello Vilay, non from your 1-5 points would be satisfied by the proposed multitenant design. It seems you are requesting complete separation of instances, this is already possible - all you need is to write some simple tool that does provisioning on your server, maybe some existing webhosting infrastructure solution would be suitable for you. The linked multitenant proposal has several strict limitations: 1/ independent tenants - no branches or divisions of one company (use mnet or other SSO solution, moodle does not scale anyway for large sites) 2/ standard admin settings would not be available in the tenant site (there are no admins the tenants, only standard manager roles) 3/ all sites have the same plugins installed (later we could add some hacks for hiding of plugins in each tenant or even course categories) Thanks for the feedback!
          Hide
          Vijay Nair added a comment -

          Hi Petr,

          I'm not sure if you understood what I was proposing. There is no physical installation of moodle involved here in my method for each client. You will still have multi tenant method. The proposal talks about producing multiple sites (with custom front page and everything else) from within the front end instead of doing the normal moodle installation on the server. So if a client want a new site for themselves then all you would need to do is login to the main moodle site and open up a form and complete the fields (name of the site and select the features you want to include to the site, etc.) and choose a theme for that site (with custom headers/logos etc.) By Admin settings I mean any one like a manager role that does the basic management of courses or specific users and there is no access for the Admin to go into other moodle sites.

          For my method, you don't need to be a web developer or system engineer to produce multiple sites. You can be a normal Admin or Webeditor to create sites for each client because there is no programming/web development involved. Its basically a pick and choose and change the colour and add a logo for each company site. I don't see that in the current moodle.

          Show
          Vijay Nair added a comment - Hi Petr, I'm not sure if you understood what I was proposing. There is no physical installation of moodle involved here in my method for each client. You will still have multi tenant method. The proposal talks about producing multiple sites (with custom front page and everything else) from within the front end instead of doing the normal moodle installation on the server. So if a client want a new site for themselves then all you would need to do is login to the main moodle site and open up a form and complete the fields (name of the site and select the features you want to include to the site, etc.) and choose a theme for that site (with custom headers/logos etc.) By Admin settings I mean any one like a manager role that does the basic management of courses or specific users and there is no access for the Admin to go into other moodle sites. For my method, you don't need to be a web developer or system engineer to produce multiple sites. You can be a normal Admin or Webeditor to create sites for each client because there is no programming/web development involved. Its basically a pick and choose and change the colour and add a logo for each company site. I don't see that in the current moodle.
          Hide
          Petr Škoda added a comment -

          Yes, it is probably a misunderstanding, my proposed solution is relative limited, you get multitenant install but with many restrictions. For some people it is good because the tenant instances will have a lot less settings/features, for others the limitations will be unacceptable and they will have to use current solutions (categories, sso, ldap, mnet, etc.).

          I looks like you want a simple way to install standard independent moodles on a shared web server, I am afraid the multitenant proposal is not a solution for you.

          Show
          Petr Škoda added a comment - Yes, it is probably a misunderstanding, my proposed solution is relative limited, you get multitenant install but with many restrictions. For some people it is good because the tenant instances will have a lot less settings/features, for others the limitations will be unacceptable and they will have to use current solutions (categories, sso, ldap, mnet, etc.). I looks like you want a simple way to install standard independent moodles on a shared web server, I am afraid the multitenant proposal is not a solution for you.
          Hide
          Vijay Nair added a comment -

          I think your proposal would be useful for me to some extend if not completely. But in either case, I do look forward to the end product here and when it is ready. I feel I might be able to use this.

          Show
          Vijay Nair added a comment - I think your proposal would be useful for me to some extend if not completely. But in either case, I do look forward to the end product here and when it is ready. I feel I might be able to use this.
          Hide
          Juan Leyva added a comment -

          I think the name "multi-tenancy sites" may lead to confusion.

          The current approach is limited mainly to courses, categories and users only.

          I.e: Google's AppEngine (cloud system) supports multi-tenancy at "database" level so it can be considered a full multi-tenancy system.

          Since I have worked with differents multi-tenancy systems (like Google's Appengine) I think that the name "multi-tenancy" is not suitable for this new feature.

          Regards

          Show
          Juan Leyva added a comment - I think the name "multi-tenancy sites" may lead to confusion. The current approach is limited mainly to courses, categories and users only. I.e: Google's AppEngine (cloud system) supports multi-tenancy at "database" level so it can be considered a full multi-tenancy system. Since I have worked with differents multi-tenancy systems (like Google's Appengine) I think that the name "multi-tenancy" is not suitable for this new feature. Regards
          Hide
          Juan Leyva added a comment -

          As Ray Lawrence says I think that some global settings should be delegated to the "tenants" level

          A new table like config_tenants (id, tenantid, name, value) that overwirtes the $CFG at the setup.php process would be a great improvement

          I know that is hard to analyze all the global settings not suitable for tenants but this will differentiate a lot a tenant site

          Also I think that a new admin block for tenants that extends the general settings block will be necesary

          PD: Multi-tenanty with "tenants global settings" is one of the top features requested by our clients (I work for a Moodle partner)

          Regards

          Show
          Juan Leyva added a comment - As Ray Lawrence says I think that some global settings should be delegated to the "tenants" level A new table like config_tenants (id, tenantid, name, value) that overwirtes the $CFG at the setup.php process would be a great improvement I know that is hard to analyze all the global settings not suitable for tenants but this will differentiate a lot a tenant site Also I think that a new admin block for tenants that extends the general settings block will be necesary PD: Multi-tenanty with "tenants global settings" is one of the top features requested by our clients (I work for a Moodle partner) Regards
          Hide
          Petr Škoda added a comment -

          Juan: What would be the difference of your multi-tenancy from multi-instance if everything was separate including all config variables?

          My design is not based on what people think multi-tenant is, but on what we can technically do with Moodle without a complete rewrite of everything, there is a high emphasis on backwards compatibility too. The difference from Google is that you can not install your own "google" instance, there is only one instance and you have to live with what you get.

          In case of moodle you can cheaply create as many instances as you want, we should not imo invest time into use cases that fit multi-instance. So yes, our multitenancy might have less features and configuration options compared to full instance, but I believe that is exactly what some people might want - fewer options/settings, lower maintenance costs and more delegation of user management.

          Another important problem is that Moodle does not scale - you can not put 2000 big schools on one server, sorry. Large multitenant systems are designed in a really different way, they are supposed to be run on a really really large cluster of servers that can be expanded on demand. Moodle is designed for one server, you usually have problems with installations that are too big and you may have to actually start partitioning them.

          Show
          Petr Škoda added a comment - Juan: What would be the difference of your multi-tenancy from multi-instance if everything was separate including all config variables? My design is not based on what people think multi-tenant is, but on what we can technically do with Moodle without a complete rewrite of everything, there is a high emphasis on backwards compatibility too. The difference from Google is that you can not install your own "google" instance, there is only one instance and you have to live with what you get. In case of moodle you can cheaply create as many instances as you want, we should not imo invest time into use cases that fit multi-instance. So yes, our multitenancy might have less features and configuration options compared to full instance, but I believe that is exactly what some people might want - fewer options/settings, lower maintenance costs and more delegation of user management. Another important problem is that Moodle does not scale - you can not put 2000 big schools on one server, sorry. Large multitenant systems are designed in a really different way, they are supposed to be run on a really really large cluster of servers that can be expanded on demand. Moodle is designed for one server, you usually have problems with installations that are too big and you may have to actually start partitioning them.
          Hide
          Tom Lanyon added a comment -

          "Moodle is designed for one server, you usually have problems with installations that are too big and you may have to actually start partitioning them."

          .. but we know that this is not the case in reality. Moodle is frequently split onto larger multi-server systems to handle single large instances (like a large university).

          Even for small tenants, I concur that the ability to delegate config settings to per-tenant admins is crucial. The path taken by other multi-tenant software we've encountered is to add tenantid to the config table and override settings per-tenant.

          I disagree with "If somebody needs to set up multiple ext DB or LDAP syncs they should definitely use full separate moodle sites" – I would suggest that one of the more common differentiators between tenants would be the authentication method and this is just as relevant for small tenants.

          In relation to the username/email uniqueness, I'd support a tenantid column on mdl_user and use of (username, tenantid) for the unique check.

          Show
          Tom Lanyon added a comment - "Moodle is designed for one server, you usually have problems with installations that are too big and you may have to actually start partitioning them." .. but we know that this is not the case in reality. Moodle is frequently split onto larger multi-server systems to handle single large instances (like a large university). Even for small tenants, I concur that the ability to delegate config settings to per-tenant admins is crucial. The path taken by other multi-tenant software we've encountered is to add tenantid to the config table and override settings per-tenant. I disagree with "If somebody needs to set up multiple ext DB or LDAP syncs they should definitely use full separate moodle sites" – I would suggest that one of the more common differentiators between tenants would be the authentication method and this is just as relevant for small tenants. In relation to the username/email uniqueness, I'd support a tenantid column on mdl_user and use of (username, tenantid) for the unique check.
          Hide
          Hubert Chathi added a comment -

          Petr, I see in the Mutitenancy plan wiki page that there is a plan to create a new moodle_context class, which similar to some of the abstracting that we were trying to do with MDL-20045. I just uploaded an updated patch to MDL-20045 that applies against Moodle 2.1. Please feel free to use that patch as you see fit.

          Show
          Hubert Chathi added a comment - Petr, I see in the Mutitenancy plan wiki page that there is a plan to create a new moodle_context class, which similar to some of the abstracting that we were trying to do with MDL-20045 . I just uploaded an updated patch to MDL-20045 that applies against Moodle 2.1. Please feel free to use that patch as you see fit.
          Hide
          Petr Škoda added a comment -

          Thanks Hubert, I was planning a bit different implementation, but still your patch is good inspiration for me. I will make sure my new code is easily hackable for you (I might be adding new cohort context soon). Thanks.

          Show
          Petr Škoda added a comment - Thanks Hubert, I was planning a bit different implementation, but still your patch is good inspiration for me. I will make sure my new code is easily hackable for you (I might be adding new cohort context soon). Thanks.
          Hide
          Petr Škoda added a comment -

          Tom: if we have unique (username,tenantid) then the normal login form would have to contain a tenant selector (when sharing one wwwroot) which is what I would like to avoid for now.

          Show
          Petr Škoda added a comment - Tom: if we have unique (username,tenantid) then the normal login form would have to contain a tenant selector (when sharing one wwwroot) which is what I would like to avoid for now.
          Hide
          Tom Lanyon added a comment -

          Petr - I had assumed that the selection of tenant is done automatically by checking something like the HTTP Host header; accessing a tenant-specific login page would allow only that tenant's users to log in, and accessing the normal 'global' login form would just assign you to the global tenant context (context 0?).

          Had you imagined that tenant would be selected based solely on username instead? Would this limit the ability to assign customisations (like themes) based on tenant until the user was logged in?

          Maybe I need to read the spec again.

          Show
          Tom Lanyon added a comment - Petr - I had assumed that the selection of tenant is done automatically by checking something like the HTTP Host header; accessing a tenant-specific login page would allow only that tenant's users to log in, and accessing the normal 'global' login form would just assign you to the global tenant context (context 0?). Had you imagined that tenant would be selected based solely on username instead? Would this limit the ability to assign customisations (like themes) based on tenant until the user was logged in? Maybe I need to read the spec again.
          Hide
          Petr Škoda added a comment -

          Not everybody has the luxury to have separate urls for each tenant, the spec proposes two options:
          1/ shared wwwroot - shared login page - we need usernames globally unique
          2/ separate wwwroots for all tenants - separate login pages - we could make the unique(username,tenantid) in the future

          Show
          Petr Škoda added a comment - Not everybody has the luxury to have separate urls for each tenant, the spec proposes two options: 1/ shared wwwroot - shared login page - we need usernames globally unique 2/ separate wwwroots for all tenants - separate login pages - we could make the unique(username,tenantid) in the future
          Hide
          Martin Dougiamas added a comment -

          After discussion we've agreed to initially target separate wwwroots for all tenant sites as that simplifies the implementation. It also allows us to present custom tenant front pages and login pages.

          Show
          Martin Dougiamas added a comment - After discussion we've agreed to initially target separate wwwroots for all tenant sites as that simplifies the implementation. It also allows us to present custom tenant front pages and login pages.
          Hide
          Andrea Bicciolo added a comment -

          The separate wwwroort and login page sound good ideas. However there are usage scenario where the same URL and same login page may be preferred. Two possible options when dealing with same wwwrott/same lgin page in a multi tenant environment:

          • use a drop down to select tenant. Pro: probably easier to implement. Cons: users are requested to know and remember their tenant.
          • let Moodle find user's tenant. Pro: very good from a user perspective. Cons: probably add some complexity

          The two option in my opinion are not mutually exclusive, maybe could be considered a admin setting.

          Show
          Andrea Bicciolo added a comment - The separate wwwroort and login page sound good ideas. However there are usage scenario where the same URL and same login page may be preferred. Two possible options when dealing with same wwwrott/same lgin page in a multi tenant environment: use a drop down to select tenant. Pro: probably easier to implement. Cons: users are requested to know and remember their tenant. let Moodle find user's tenant. Pro: very good from a user perspective. Cons: probably add some complexity The two option in my opinion are not mutually exclusive, maybe could be considered a admin setting.
          Hide
          Tom Lanyon added a comment -

          I'm worried about the potential for multiple different copies of Moodle accessing the same multi-tenant database.

          Surely there's potential incompatibilities between different code (different Moodle versions, different mod versions) talking with the same data set. This would all be fine if all code was fully forwards and backwards compatible, but how often does that happen?

          Show
          Tom Lanyon added a comment - I'm worried about the potential for multiple different copies of Moodle accessing the same multi-tenant database. Surely there's potential incompatibilities between different code (different Moodle versions, different mod versions) talking with the same data set. This would all be fine if all code was fully forwards and backwards compatible, but how often does that happen?
          Hide
          Petr Škoda added a comment -

          Tom: different moodle versions?? This was never proposed, there would be only one dirroot, the code would read the URL via which it was accessed and select the appropriate tenant.

          Show
          Petr Škoda added a comment - Tom: different moodle versions?? This was never proposed, there would be only one dirroot, the code would read the URL via which it was accessed and select the appropriate tenant.
          Hide
          Tom Lanyon added a comment -

          Petr: oh, right. Sorry, I read your previous comment incorrectly. Yes, what you've clarified (code checks HTTP_HOST and selects appropriate tenant, or falls back to a default drop down list) is what I'd like to see.

          Show
          Tom Lanyon added a comment - Petr: oh, right. Sorry, I read your previous comment incorrectly. Yes, what you've clarified (code checks HTTP_HOST and selects appropriate tenant, or falls back to a default drop down list) is what I'd like to see.
          Hide
          Andrea Bicciolo added a comment -

          Some thoughts about the Auth plans as reported in docs: "No changes expected, we should not mess with the user table and auth plugins at this point because tenants are expected to be small".

          Under certain circumstances tenants are not going to be small, and external auth (such as LDAP or External DB) could be a requirement, for example a whole university with many faculty, where each faculty is a tenant. The Auth plugins should be able to support tenant.

          Show
          Andrea Bicciolo added a comment - Some thoughts about the Auth plans as reported in docs: "No changes expected, we should not mess with the user table and auth plugins at this point because tenants are expected to be small". Under certain circumstances tenants are not going to be small, and external auth (such as LDAP or External DB) could be a requirement, for example a whole university with many faculty, where each faculty is a tenant. The Auth plugins should be able to support tenant.
          Hide
          Andrea Bicciolo added a comment - - edited

          Consioderations about cohorts. From the Moodle docs: "Cohorts are not affected by this change at all", however in the Implementation plan, point 1.7: "create new cohort context".

          Will cohort become context then ? If yes, in my opinion this is a very good improvement.

          Show
          Andrea Bicciolo added a comment - - edited Consioderations about cohorts. From the Moodle docs: "Cohorts are not affected by this change at all", however in the Implementation plan, point 1.7: "create new cohort context". Will cohort become context then ? If yes, in my opinion this is a very good improvement.
          Hide
          Petr Škoda added a comment -

          thanks, I have removed the cohort item

          Show
          Petr Škoda added a comment - thanks, I have removed the cohort item
          Hide
          Sebastian Giovannetti added a comment -

          Hi Petr, im new on this and i have some questions about this and i hope you can help me if you please.

          I've been assigned in my company to a project wich involves to modify the user interface to be more user friendly, and my first task is to know what version will we use to modify.

          One of the clients requirements is to have this multi-tenancy functionality and i know that the next version of moodle will have it.

          We need to join some section like forums, blogs, to hide alot of the actual menu bars and create some new, using the same functions that moodle provide. So, in your opinion will be better to begin to work using the last stable version or use some develop version and keep traking of his advance like yours in github?

          Will this version change have major changes in the way to reach user-course data? I supose that will have alot of changes on this and i dont know how to calculate the risk on use the stable version becouse our death line is december 15th.

          I would glade some help, thank you!

          Show
          Sebastian Giovannetti added a comment - Hi Petr, im new on this and i have some questions about this and i hope you can help me if you please. I've been assigned in my company to a project wich involves to modify the user interface to be more user friendly, and my first task is to know what version will we use to modify. One of the clients requirements is to have this multi-tenancy functionality and i know that the next version of moodle will have it. We need to join some section like forums, blogs, to hide alot of the actual menu bars and create some new, using the same functions that moodle provide. So, in your opinion will be better to begin to work using the last stable version or use some develop version and keep traking of his advance like yours in github? Will this version change have major changes in the way to reach user-course data? I supose that will have alot of changes on this and i dont know how to calculate the risk on use the stable version becouse our death line is december 15th. I would glade some help, thank you!
          Hide
          Petr Škoda added a comment -

          Hello,

          I do not know exactly when and what will be part of stable moodle release, I am still refactoring and writing new code, solving various challenges along the way. It can be integrated only if it is fully working, test branch should be definitely available at the time of Moodle 2.2 release.

          I agree we need a lot more user friendly interface.

          Show
          Petr Škoda added a comment - Hello, I do not know exactly when and what will be part of stable moodle release, I am still refactoring and writing new code, solving various challenges along the way. It can be integrated only if it is fully working, test branch should be definitely available at the time of Moodle 2.2 release. I agree we need a lot more user friendly interface.
          Hide
          Sebastian Giovannetti added a comment -

          So you cant assure that this will be part of 2.2 release in December.

          Show
          Sebastian Giovannetti added a comment - So you cant assure that this will be part of 2.2 release in December.
          Hide
          Petr Škoda added a comment -

          The code freeze for Moodle 2.2 is supposed to be in 2 weeks, the multitenant patch is not created yet, I doubt it could reach production quality that is necessary for integration into 2.2dev branch in the next few weeks. I believe there will a be a branch in git ready for testing at the time we release Moodle 2.2.

          Show
          Petr Škoda added a comment - The code freeze for Moodle 2.2 is supposed to be in 2 weeks, the multitenant patch is not created yet, I doubt it could reach production quality that is necessary for integration into 2.2dev branch in the next few weeks. I believe there will a be a branch in git ready for testing at the time we release Moodle 2.2.
          Hide
          Ray Lawrence added a comment -

          +1 on the expectation that tenants will be small is wide of the mark.

          Of course there's an issue with a debate about this here as "small" hasn't been defined.

          + 1 on separate wwwroots that will enable custom login pages too.

          Show
          Ray Lawrence added a comment - +1 on the expectation that tenants will be small is wide of the mark. Of course there's an issue with a debate about this here as "small" hasn't been defined. + 1 on separate wwwroots that will enable custom login pages too.
          Hide
          Daniel Neis added a comment -

          Hello,

          first of all, congratulations for the initiative and the work done so far.

          I was very excited when i first saw this issue, but some things lowered this excitement.
          To list a few things i would expect from Moodle's Multi-Tenancy:

          • To be like Wordpress Multi-site (http://codex.wordpress.org/Create_A_Network)
          • To have a centralised user base, so i can "assign" users to their tenants.
          • To have a fully-configurable tenant, but to inherit everything i didn't setup yet from global site
          • To have disk-space and course quantity quotas for each tenant
          • To have Centralized reports

          This would be the "holy grail" for our institution, Universidade Federal de Santa Catarina, where we have about 10 differente Moodle installations, with most of users being able to access a subset of them.

          Kind regards,
          Daniel

          Show
          Daniel Neis added a comment - Hello, first of all, congratulations for the initiative and the work done so far. I was very excited when i first saw this issue, but some things lowered this excitement. To list a few things i would expect from Moodle's Multi-Tenancy: To be like Wordpress Multi-site ( http://codex.wordpress.org/Create_A_Network ) To have a centralised user base, so i can "assign" users to their tenants. To have a fully-configurable tenant, but to inherit everything i didn't setup yet from global site To have disk-space and course quantity quotas for each tenant To have Centralized reports This would be the "holy grail" for our institution, Universidade Federal de Santa Catarina, where we have about 10 differente Moodle installations, with most of users being able to access a subset of them. Kind regards, Daniel
          Hide
          Ray Lawrence added a comment -

          A thought occurred to me about self registration. Currently users are directed to the course index page. This isn't ideal in Moodle atm see MDL-29979

          A "site" course index page would be inappropriate on an instance with multiple tenants. Which page will self-registrants for a particular tenant be directed to?

          Show
          Ray Lawrence added a comment - A thought occurred to me about self registration. Currently users are directed to the course index page. This isn't ideal in Moodle atm see MDL-29979 A "site" course index page would be inappropriate on an instance with multiple tenants. Which page will self-registrants for a particular tenant be directed to?
          Hide
          Juan Leyva added a comment -

          I was looking the code Petr is developing at:

          https://github.com/skodak/moodle/tree/wip_multitenant_3-57

          It seems that one user in multiple tenants will be supported using a cohort sync. (Users in one cohort linked to the tenant will be enroled there)
          There will be a block for jumping between tenants
          Each tenant will have also their own subdomain

          Petr, can you confirm this?

          Show
          Juan Leyva added a comment - I was looking the code Petr is developing at: https://github.com/skodak/moodle/tree/wip_multitenant_3-57 It seems that one user in multiple tenants will be supported using a cohort sync. (Users in one cohort linked to the tenant will be enroled there) There will be a block for jumping between tenants Each tenant will have also their own subdomain Petr, can you confirm this?
          Hide
          Martin Dougiamas added a comment -

          Petr has also proposed some milestones and a timeline for completing this development:

          https://github.com/skodak/moodle/blob/wip_multitenant_3-57/multitenants_wip.md

          This is obviously much much longer and more complex than originally envisaged.

          I have questions about whether it is worth proceeding at all with such a invasive and major change in core code, since only a very small percentage of sites will even be interested in this feature.

          What do you think?

          Show
          Martin Dougiamas added a comment - Petr has also proposed some milestones and a timeline for completing this development: https://github.com/skodak/moodle/blob/wip_multitenant_3-57/multitenants_wip.md This is obviously much much longer and more complex than originally envisaged. I have questions about whether it is worth proceeding at all with such a invasive and major change in core code, since only a very small percentage of sites will even be interested in this feature. What do you think?
          Hide
          Ray Lawrence added a comment -

          The ability to have a Moodle sites where different "groups" of users e.g. companies, departments, clients can be accommodated on a single site whilst being completely separated from each other is highly desirable to many (many) clients and is much anticipated.

          It's very important. If it takes longer so be it but Moodle needs to have this facility.

          Show
          Ray Lawrence added a comment - The ability to have a Moodle sites where different "groups" of users e.g. companies, departments, clients can be accommodated on a single site whilst being completely separated from each other is highly desirable to many (many) clients and is much anticipated. It's very important. If it takes longer so be it but Moodle needs to have this facility.
          Hide
          Dan Poltawski added a comment -

          That this is a very complex and invasive change does not surprise me considering the current design of Moodle.

          So I wonder:
          1) What are the 'multi-tenant' advantages which separate sites do not fulfil? I am still really unclear on this.

          2) Can we instead focus effort on making 'multiple-moodle' management easier? This could be thinks:

          • Running multiple sites off one codebase 'natural' (I think drupal has a feature like this with a sites/ directory)
          • Tools to make 10 moodle upgrades easy
          • Import/export features of key areas where data needs to be shared between 'tenants'

          Really I am so unclear about 1) and would love to hear the advantages.

          Show
          Dan Poltawski added a comment - That this is a very complex and invasive change does not surprise me considering the current design of Moodle. So I wonder: 1) What are the 'multi-tenant' advantages which separate sites do not fulfil? I am still really unclear on this. 2) Can we instead focus effort on making 'multiple-moodle' management easier? This could be thinks: Running multiple sites off one codebase 'natural' (I think drupal has a feature like this with a sites/ directory) Tools to make 10 moodle upgrades easy Import/export features of key areas where data needs to be shared between 'tenants' Really I am so unclear about 1) and would love to hear the advantages.
          Hide
          Dan Poltawski added a comment -

          So I read some of the comments above to comment on the 'muliti-moodle' management tools:

          To be like Wordpress Multi-site (http://codex.wordpress.org/Create_A_Network)

          I think on skimming this is very similar to my thoughts - still separate sites with tools for helping management.

          To have a centralised user base, so i can "assign" users to their tenants.

          Can this be easier export/import of users between sites?

          To have a fully-configurable tenant, but to inherit everything i didn't setup yet from global site

          Can we get the the moodle flavours project integrated to allow the 'inheriting'. You obviously then get fully configurable.

          • To have disk-space and course quantity quotas for each tenant
          • To have Centralized reports

          OK a centralised reporting tool is a requirement - so can we make a tool which sits outside of all the Moodles and aggregates the data from all the sites (using for example web services) for central reporting? This has the advantage of allowing centralised reporting for partners across all their sites (even if completely separate).

          Show
          Dan Poltawski added a comment - So I read some of the comments above to comment on the 'muliti-moodle' management tools: To be like Wordpress Multi-site ( http://codex.wordpress.org/Create_A_Network ) I think on skimming this is very similar to my thoughts - still separate sites with tools for helping management. To have a centralised user base, so i can "assign" users to their tenants. Can this be easier export/import of users between sites? To have a fully-configurable tenant, but to inherit everything i didn't setup yet from global site Can we get the the moodle flavours project integrated to allow the 'inheriting'. You obviously then get fully configurable. • To have disk-space and course quantity quotas for each tenant • To have Centralized reports OK a centralised reporting tool is a requirement - so can we make a tool which sits outside of all the Moodles and aggregates the data from all the sites (using for example web services) for central reporting? This has the advantage of allowing centralised reporting for partners across all their sites (even if completely separate).
          Hide
          Juan Leyva added a comment -

          As far as a I can see most of the core changes are for replacing SITEID with SITE->id and for adding the new global $TENANT

          We (CV&A Consulting) have a lot of clients waiting for this feature. We particularly have clients migrating from Blackboard and SABA waiting for this feature that is crucial for him

          Show
          Juan Leyva added a comment - As far as a I can see most of the core changes are for replacing SITEID with SITE->id and for adding the new global $TENANT We (CV&A Consulting) have a lot of clients waiting for this feature. We particularly have clients migrating from Blackboard and SABA waiting for this feature that is crucial for him
          Hide
          Richard Sharples added a comment -

          Agree with Juan and Ray this feature would be incredibly valuable.

          Show
          Richard Sharples added a comment - Agree with Juan and Ray this feature would be incredibly valuable.
          Hide
          Mary Evans added a comment -

          Would it be feasible to have a Moodle with two lanes. A 'SLOW' lane which could be Moodle 2.2 as it is now, but with slower development for those who want a nice and easy Moodle that works. And a 'FAST' lane that goes all out for Moodle Tenancy, which would be perhaps more useful in the long run of things, if what I am reading here is anything to go by?

          Just my simple 2 cents worth

          Show
          Mary Evans added a comment - Would it be feasible to have a Moodle with two lanes. A 'SLOW' lane which could be Moodle 2.2 as it is now, but with slower development for those who want a nice and easy Moodle that works. And a 'FAST' lane that goes all out for Moodle Tenancy, which would be perhaps more useful in the long run of things, if what I am reading here is anything to go by? Just my simple 2 cents worth
          Hide
          Ray Lawrence added a comment -

          To Dan:

          Ref your (1) query above.

          Many organisations want the facility to work with various users groups where:

          • Users of each group have no awareness of each other or their courses and have no facility to communicate across the separated groups.
          • Each group has a specific specific site landing page that is not visible to others (when logged in).
          • Branding is different (if required) for that group - from the landing page onwards.

          The want these facilities within a single site and don't want the overhead of managing multiple instances.

          Ref (2): An official i.e. HQ support multiple site management option for a single code base could be the way forward. Sites that don't need this don't enable it - simple. The inevitable compromises that would be faced with options available to tenants would be avoided.

          So, is there another way to address this that isn't so invasive an problematic?

          Show
          Ray Lawrence added a comment - To Dan: Ref your (1) query above. Many organisations want the facility to work with various users groups where: Users of each group have no awareness of each other or their courses and have no facility to communicate across the separated groups. Each group has a specific specific site landing page that is not visible to others (when logged in). Branding is different (if required) for that group - from the landing page onwards. The want these facilities within a single site and don't want the overhead of managing multiple instances. Ref (2): An official i.e. HQ support multiple site management option for a single code base could be the way forward. Sites that don't need this don't enable it - simple. The inevitable compromises that would be faced with options available to tenants would be avoided. So, is there another way to address this that isn't so invasive an problematic?
          Hide
          Dan Poltawski added a comment -

          I personally think if we work on reducing 'the the overhead of managing multiple instances' this would be sustainable and also give advantages to many others in addition to those interested in multi tenancy specifically. The question is what are the overheads we to address - initial thoughts from above:
          Managing

          • Upgrades
          • Settings (presets shared across all sites)
          • Centralised reporting
          Show
          Dan Poltawski added a comment - I personally think if we work on reducing 'the the overhead of managing multiple instances' this would be sustainable and also give advantages to many others in addition to those interested in multi tenancy specifically. The question is what are the overheads we to address - initial thoughts from above: Managing Upgrades Settings (presets shared across all sites) Centralised reporting
          Hide
          Vijay Nair added a comment -

          I believe that if we get this working, then Moodle will have a real edge over other Lms systems designed specifically for elearning and lms suppliers to host multiple instances of the system. It doesn't matter if it takes longer to achieve this or if major change is required in the core code. The fact remains that Organisations especially service providers are going to need this feature and save money over purchasing commercial lms systems to do the same. The way I see, commercial lms systems will boast about having this feature over Moodle. I vote for Moodle to have this feature.

          Show
          Vijay Nair added a comment - I believe that if we get this working, then Moodle will have a real edge over other Lms systems designed specifically for elearning and lms suppliers to host multiple instances of the system. It doesn't matter if it takes longer to achieve this or if major change is required in the core code. The fact remains that Organisations especially service providers are going to need this feature and save money over purchasing commercial lms systems to do the same. The way I see, commercial lms systems will boast about having this feature over Moodle. I vote for Moodle to have this feature.
          Hide
          Wesley Janik added a comment -

          Speaking on behalf of a company looking to move to Moodle from a commercial system, I agree with Vijay completely. The one thing stalling our migration from our commercial LMS to Moodle is multi-tenancy. We would love to move to Moodle, but simply can't without this functionality.

          Show
          Wesley Janik added a comment - Speaking on behalf of a company looking to move to Moodle from a commercial system, I agree with Vijay completely. The one thing stalling our migration from our commercial LMS to Moodle is multi-tenancy. We would love to move to Moodle, but simply can't without this functionality.
          Hide
          Martin Dougiamas added a comment -

          One thing I am wondering is if the current multitenant design limitations are a problem for the people advocating it. Please make very sure you understand what it can and can't do before you advocate for it. It's not a magic solution for organisational groups in large corporations, nor is it comparable to true virtual hosting. It's a sort of mid-way solution that we think covers a lot of the use cases but not all of them.

          Would true multi-Moodle management be better, with some functionality to move data around and sync things between sites? Can I have some thoughts from people about this, and if it would definitely NOT meet their needs? If not, why not? Be as specific with examples as you like.

          Show
          Martin Dougiamas added a comment - One thing I am wondering is if the current multitenant design limitations are a problem for the people advocating it. Please make very sure you understand what it can and can't do before you advocate for it. It's not a magic solution for organisational groups in large corporations, nor is it comparable to true virtual hosting. It's a sort of mid-way solution that we think covers a lot of the use cases but not all of them. Would true multi-Moodle management be better, with some functionality to move data around and sync things between sites? Can I have some thoughts from people about this, and if it would definitely NOT meet their needs? If not, why not? Be as specific with examples as you like.
          Hide
          Juan Leyva added a comment -

          Hi Martin,

          you are totally right but I think that people are advocating for having a way to host multiple sites (not the technical solution)

          They doesn't mind if this is resolved using a multitenancy approach or a multi-instances with a control panel approach.

          The point is that since we are all in a hurry for having this feature as soon as posible (2.3) most of us are advocating for the Petr solution because there are a lot of work done.

          So I have an "open question". If we can "unblock" this adding our thoughs and needs... are we in time for having this feature in Moodle 2.3?

          Regards

          Show
          Juan Leyva added a comment - Hi Martin, you are totally right but I think that people are advocating for having a way to host multiple sites (not the technical solution) They doesn't mind if this is resolved using a multitenancy approach or a multi-instances with a control panel approach. The point is that since we are all in a hurry for having this feature as soon as posible (2.3) most of us are advocating for the Petr solution because there are a lot of work done. So I have an "open question". If we can "unblock" this adding our thoughs and needs... are we in time for having this feature in Moodle 2.3? Regards
          Hide
          Petr Škoda added a comment -

          Hmm, control panel software for multi instance would be order of magnitude easier to implement than the multitenant because it would require only small changes in current moodle code - most of it would be external tool that would not even have to use PHP. Users would not see big difference because in any case we need to use separate www roots for security reasons.

          What could it do?

          • SSO and user management across sites
          • one click installs and automatic upgrades with templates
          • remote setting management with presets
          • reporting across sites
          • sharing of files across sites
          • support for multiple web servers and databases
          • there could be plugins for common virtualised solutions
          Show
          Petr Škoda added a comment - Hmm, control panel software for multi instance would be order of magnitude easier to implement than the multitenant because it would require only small changes in current moodle code - most of it would be external tool that would not even have to use PHP. Users would not see big difference because in any case we need to use separate www roots for security reasons. What could it do? SSO and user management across sites one click installs and automatic upgrades with templates remote setting management with presets reporting across sites sharing of files across sites support for multiple web servers and databases there could be plugins for common virtualised solutions
          Hide
          Jordi Vila added a comment -

          As Juan, Ray, Richard and others said it is not an important feature for Moodle, it's been CRUCIAL and requested for years now! As they mention for any large organization (mostly corporate users and universities, though other consulting or professional training firms are also requesting this feature) it is so interesting and requested for a long time (site-wide groups has been requested to Martin in every single Moodlemoot, I recall). For those companies wanting to move from other enterprise LMSs like SABA, SumTOTAL, Bb,... it's a "must have" feature.

          We don't care that much on the technical approach taken as long as it is something that is easy to administer by end users (site administrators mainly).

          It would be very interesting to know if this could be implemented to be on Moodle 2.3 as stated in the roadmap. You guys see this feasible?

          I will have Juan Leyva watch very closely onto this, follow up and provide any insight and help needed.

          Show
          Jordi Vila added a comment - As Juan, Ray, Richard and others said it is not an important feature for Moodle, it's been CRUCIAL and requested for years now! As they mention for any large organization (mostly corporate users and universities, though other consulting or professional training firms are also requesting this feature) it is so interesting and requested for a long time (site-wide groups has been requested to Martin in every single Moodlemoot, I recall). For those companies wanting to move from other enterprise LMSs like SABA, SumTOTAL, Bb,... it's a "must have" feature. We don't care that much on the technical approach taken as long as it is something that is easy to administer by end users (site administrators mainly). It would be very interesting to know if this could be implemented to be on Moodle 2.3 as stated in the roadmap. You guys see this feasible? I will have Juan Leyva watch very closely onto this, follow up and provide any insight and help needed.
          Hide
          Juan Leyva added a comment -

          These are my thoughts based on our customers needs:

          (I also add some of the Petr points with comments)

          • We need a way for having multiple sites inside a Moodle installation
          • The sites should have "site administrators" for user, course and global options (theme, language, etc..) administration
          • Must of the Moodle global settings should work for a single instance (presets and templates are a very good idea)
          • Creating an deleting sites should be easy for any manager. A control panel (that can be a Moodle installation with a admin tool plugin)
            • One click installs and automatic upgrades with templates
            • Remote setting management with presets
          • There should be a "base site", a site where all the users in all the instances are present. SSO between instances can be done as the Petr code, using a block like the Mnet block
          • Creating a site must not imply perform any action in your server or database settings (Create a new database, directory for the moodledata with privileges, etc..)
          • SSO and user management across sites (Moodle network would be a good choice for this?)
          • A way to cross reporting (Google fusion tables way of do these?)
          • Sharing of files across sites (Repository plugin?)
          • Usersname should be the same between moodle instances for cross reporting, but any instance should work as a independent instance (they should provide their own login)
          • Cohorst sync will be amazing (Sync cohorts with instances) I mean, users from cohort X in the control panel will be automatically created in the instance N

          Technical notes:

          • I think that one code and multiple databases approach is the best way to achieve this
          • All the instances shares the same code, but each instance has their own database and moodledata
          • This can make upgrading and bug fixing easier
          • Sharing the same code have some potential issues:
            • When a plugin is installed it will be installed in all the instances
            • Some global options (like uninstalls plugins) should be disabled at instance level
            • The list of available themes will be available for all the instances (Themes should be in moodledata maybe? I think this have been proposed before)
          • I think there are two options for creating the sites databases:
          • Use a db prefix different for every single instance (likeWordpress works) mdl1_, mdl2, mdl3_ But Moodle hast a lot of tables (200 tables per installation) so 5 instances means 1000 tables
          • Use a dbname different for every single instance. (Sharing the dbuser and dbpassword)
          • CLI upgrading scripts should support multi instances sites
          • The control panel could be a new admin tool plugin
          • There could be a advanced features setting for enabling multi instances
          • Once enabled, the current site will the "control panel" site
          • Using the admin tool plugin will be easy create new instances
          Show
          Juan Leyva added a comment - These are my thoughts based on our customers needs: (I also add some of the Petr points with comments) We need a way for having multiple sites inside a Moodle installation The sites should have "site administrators" for user, course and global options (theme, language, etc..) administration Must of the Moodle global settings should work for a single instance (presets and templates are a very good idea) Creating an deleting sites should be easy for any manager. A control panel (that can be a Moodle installation with a admin tool plugin) One click installs and automatic upgrades with templates Remote setting management with presets There should be a "base site", a site where all the users in all the instances are present. SSO between instances can be done as the Petr code, using a block like the Mnet block Creating a site must not imply perform any action in your server or database settings (Create a new database, directory for the moodledata with privileges, etc..) SSO and user management across sites (Moodle network would be a good choice for this?) A way to cross reporting (Google fusion tables way of do these?) Sharing of files across sites (Repository plugin?) Usersname should be the same between moodle instances for cross reporting, but any instance should work as a independent instance (they should provide their own login) Cohorst sync will be amazing (Sync cohorts with instances) I mean, users from cohort X in the control panel will be automatically created in the instance N Technical notes: I think that one code and multiple databases approach is the best way to achieve this All the instances shares the same code, but each instance has their own database and moodledata This can make upgrading and bug fixing easier Sharing the same code have some potential issues: When a plugin is installed it will be installed in all the instances Some global options (like uninstalls plugins) should be disabled at instance level The list of available themes will be available for all the instances (Themes should be in moodledata maybe? I think this have been proposed before) I think there are two options for creating the sites databases: Use a db prefix different for every single instance (likeWordpress works) mdl1_, mdl2, mdl3_ But Moodle hast a lot of tables (200 tables per installation) so 5 instances means 1000 tables Use a dbname different for every single instance. (Sharing the dbuser and dbpassword) CLI upgrading scripts should support multi instances sites The control panel could be a new admin tool plugin There could be a advanced features setting for enabling multi instances Once enabled, the current site will the "control panel" site Using the admin tool plugin will be easy create new instances
          Hide
          Andrea Bicciolo added a comment -

          The proposal from Petr (external tool) is interesting, however it appears to me could be applied well for some scenarios (for example a whole university with several faculties) rather than a corporate or a commercial training provider. In the latter cases it is more interesting a single environment but clearly separated for each given "group" of users.

          Maybe a simpler possibility could be extending the concept of cohorts, making them contexts and allow specific "cohort roles" manage their own users and course catalogs. That would not address the different URLs for each tenant (unless some sort of masking could be used), but would allow simpler central management of users and courses, context based reporting, separation of course according to cohorts, cohort-based users management, possibility to allow users to switch cohort (for example when a users changes faculty attended or change the company department he works in).

          If I correctly recall in the dev doc there were a page about initial cohort development ideas (that I'm currently unable to find) where similar concepts was already present.

          Show
          Andrea Bicciolo added a comment - The proposal from Petr (external tool) is interesting, however it appears to me could be applied well for some scenarios (for example a whole university with several faculties) rather than a corporate or a commercial training provider. In the latter cases it is more interesting a single environment but clearly separated for each given "group" of users. Maybe a simpler possibility could be extending the concept of cohorts, making them contexts and allow specific "cohort roles" manage their own users and course catalogs. That would not address the different URLs for each tenant (unless some sort of masking could be used), but would allow simpler central management of users and courses, context based reporting, separation of course according to cohorts, cohort-based users management, possibility to allow users to switch cohort (for example when a users changes faculty attended or change the company department he works in). If I correctly recall in the dev doc there were a page about initial cohort development ideas (that I'm currently unable to find) where similar concepts was already present.
          Hide
          Ray Lawrence added a comment -

          I've not looked any any code that's been developed so my understanding of the current solution is based on the initial spec. and posts here.

          A concern that I had/have about the current proposal is that the admin functions delegated to tenants would be too limited i.e they would reside with the global administrator for example all authentication options should be available for each tenant not just once for the site.

          Naturally within the proposed solution there would compromises to accept and in some cases those compromises would be a step too far so a multi-instance approach would still be required.

          If there was a way for each tenant to have full Moodle functionality that would be great.

          Tools to make the management of multi instances would be great but let's not get carried away with this yet. One of the principal requirements is multi-tenancy on a single site. Tools to manage multiple instances may well be the solution but won't this increase the effort to maintain the arrangement proportionately? That's not what administrators or we (service providers) want.

          I hope others will refine the following list of key features that our clients are looking for from "multi-tenancy".

          The ability to manage multiple "tenants" on Moodle instance installed with a single code base.
          Tenants to be completely separated:
          1. No opportunities to communicate between tenants
          2. No visibility of each other's courses or categories
          3. A tenant specific home page
          4. Tenant specific branding from the tenant home page onwards (with the usual category, course etc options too)
          5. Tenant specific reporting capabilities
          6. Tenant specific user management options.
          7. The global administrator should be able to "reserve" some tenant management tasks e.g. global admin manages ext db auth but tenant admin can upload users via CSV
          8. As many system admin options that are possible (and sensible)to be available per tenant e.g. site policy, languages, location, theme, repositories
          9. The ability for some users to work across tenants without multiple logins - global admins (of course), support staff,
          10. Tenant "admins" (probably more like the current Manager)

          Petr's comments 13/Jan/12 5:12 PM seem to be moving away from the above.

          Show
          Ray Lawrence added a comment - I've not looked any any code that's been developed so my understanding of the current solution is based on the initial spec. and posts here. A concern that I had/have about the current proposal is that the admin functions delegated to tenants would be too limited i.e they would reside with the global administrator for example all authentication options should be available for each tenant not just once for the site. Naturally within the proposed solution there would compromises to accept and in some cases those compromises would be a step too far so a multi-instance approach would still be required. If there was a way for each tenant to have full Moodle functionality that would be great. Tools to make the management of multi instances would be great but let's not get carried away with this yet. One of the principal requirements is multi-tenancy on a single site. Tools to manage multiple instances may well be the solution but won't this increase the effort to maintain the arrangement proportionately? That's not what administrators or we (service providers) want. I hope others will refine the following list of key features that our clients are looking for from "multi-tenancy". The ability to manage multiple "tenants" on Moodle instance installed with a single code base. Tenants to be completely separated: 1. No opportunities to communicate between tenants 2. No visibility of each other's courses or categories 3. A tenant specific home page 4. Tenant specific branding from the tenant home page onwards (with the usual category, course etc options too) 5. Tenant specific reporting capabilities 6. Tenant specific user management options. 7. The global administrator should be able to "reserve" some tenant management tasks e.g. global admin manages ext db auth but tenant admin can upload users via CSV 8. As many system admin options that are possible (and sensible)to be available per tenant e.g. site policy, languages, location, theme, repositories 9. The ability for some users to work across tenants without multiple logins - global admins (of course), support staff, 10. Tenant "admins" (probably more like the current Manager) Petr's comments 13/Jan/12 5:12 PM seem to be moving away from the above.
          Hide
          Luis de Vasconcelos added a comment -

          How will the "one codebase and multiple databases" approach work when it comes to installing optional modules and plugins? If you only have one codebase then will everybody have to share the same functionality in Moodle, i.e. the same optional modules, plugins and/or admin reports? Can you install a module, plugin or admin report for Site X only - and not Site Y and Site Z when you only have one codebase?

          Show
          Luis de Vasconcelos added a comment - How will the "one codebase and multiple databases" approach work when it comes to installing optional modules and plugins? If you only have one codebase then will everybody have to share the same functionality in Moodle, i.e. the same optional modules, plugins and/or admin reports? Can you install a module, plugin or admin report for Site X only - and not Site Y and Site Z when you only have one codebase?
          Hide
          Ray Lawrence added a comment -

          "How will the "one codebase and multiple databases" approach work when it comes to installing optional modules and plugins?"

          I don't think this is possible or needed. If the requirement is for a variance of functionality at this level it's a separate instance job.

          Show
          Ray Lawrence added a comment - "How will the "one codebase and multiple databases" approach work when it comes to installing optional modules and plugins?" I don't think this is possible or needed. If the requirement is for a variance of functionality at this level it's a separate instance job.
          Hide
          Dan Poltawski added a comment -

          Tools to make the management of multi instances would be great but let's not get carried away with this yet. One of the principal requirements is multi-tenancy on a single site. Tools to manage multiple instances may well be the solution but won't this increase the effort to maintain the arrangement proportionately? That's not what administrators or we (service providers) want.

          What do you mean by a 'single site' though? Even in the current multi-tenancy proposal there would need to be a different wwwroot (url) for each site.

          My thought on the tools to manage multiple instances is that the point of doing this would be to all but eliminate the effort which is required making managing multiple sites hard. I again am asking what are these things which cause this 'effort' and also what are the barriers in functionality which prevent multiple sites being effective.

          Show
          Dan Poltawski added a comment - Tools to make the management of multi instances would be great but let's not get carried away with this yet. One of the principal requirements is multi-tenancy on a single site. Tools to manage multiple instances may well be the solution but won't this increase the effort to maintain the arrangement proportionately? That's not what administrators or we (service providers) want. What do you mean by a 'single site' though? Even in the current multi-tenancy proposal there would need to be a different wwwroot (url) for each site. My thought on the tools to manage multiple instances is that the point of doing this would be to all but eliminate the effort which is required making managing multiple sites hard. I again am asking what are these things which cause this 'effort' and also what are the barriers in functionality which prevent multiple sites being effective.
          Hide
          Ray Lawrence added a comment -

          Single as in, um, single.

          So the global admin logs into one site and manages the tenants on that "single" site.

          Use case:

          Successful global training business offering courses to competing companies, client confidence and confidentiality are important. Whole set up is administered (Moodle, not server) by 2-3 people.

          What they typically want is to be able to set up clients on a single (that word again) site. They don't want to manage separate sites or navigate between separate sites.

          There is some commonality across their client requirements, or rather how they decide to make their offering to their clients. This is accepted as a trade off for using a single system. If they want a completely free hand to tweak every conceivable setting they need separate instances.

          URL: Clearly there would need to be different landing page URLs eg.

          klm.megatraining.com or megatraining.com/klm
          emirates.megatraining.com or megatraining.com/emirates

          Does there need to be a different url beyond that?

          Although not the best example as it's somewhat simpler than Moodle, I'm looking at an email newsletter application/service. I can log in as the overall admin, I can create clients if I wish and grant clients varying permissions. Clients arrive at the same login page (akin to forced login mode in Moodle), when they log in they see their own area only. I think this sort of arrangement is pretty common, of course retro fitting to an existing complex LMS isn't necessarily going to be easy.

          Does that help?

          Show
          Ray Lawrence added a comment - Single as in, um, single. So the global admin logs into one site and manages the tenants on that "single" site. Use case: Successful global training business offering courses to competing companies, client confidence and confidentiality are important. Whole set up is administered (Moodle, not server) by 2-3 people. What they typically want is to be able to set up clients on a single (that word again) site. They don't want to manage separate sites or navigate between separate sites. There is some commonality across their client requirements, or rather how they decide to make their offering to their clients. This is accepted as a trade off for using a single system. If they want a completely free hand to tweak every conceivable setting they need separate instances. URL: Clearly there would need to be different landing page URLs eg. klm.megatraining.com or megatraining.com/klm emirates.megatraining.com or megatraining.com/emirates Does there need to be a different url beyond that? Although not the best example as it's somewhat simpler than Moodle, I'm looking at an email newsletter application/service. I can log in as the overall admin, I can create clients if I wish and grant clients varying permissions. Clients arrive at the same login page (akin to forced login mode in Moodle), when they log in they see their own area only. I think this sort of arrangement is pretty common, of course retro fitting to an existing complex LMS isn't necessarily going to be easy. Does that help?
          Hide
          Luis de Vasconcelos added a comment - - edited

          Ray, should you be running an "email newsletter application/service" from Moodle? Wouldn't something like Joomla be better for that? Moodle is a LMS, not a CMS. But you know that!

          Show
          Luis de Vasconcelos added a comment - - edited Ray, should you be running an "email newsletter application/service" from Moodle? Wouldn't something like Joomla be better for that? Moodle is a LMS, not a CMS. But you know that!
          Hide
          Ray Lawrence added a comment -

          It's not in Moodle or Joomla. It's a separate service, it was the first thing that came to mind to illustrate the point.

          Show
          Ray Lawrence added a comment - It's not in Moodle or Joomla. It's a separate service, it was the first thing that came to mind to illustrate the point.
          Hide
          Dan Poltawski added a comment -

          Yep the use case is useful - thanks!

          I am still convinced that we would be better placed spending our time making tools to make the use case you describe work with multiple moodle installs. From a technical point of view it seems to me that the maximum flexibility comes with multiple installs managed with new tools to provide the multi-tenancy feature. The scope of what is required by a single tenant seems to be no different than a Moodle install and again from a technical point of view it seems we are introducing another 'layer' which is pretty much the same as Moodle installation.

          Show
          Dan Poltawski added a comment - Yep the use case is useful - thanks! I am still convinced that we would be better placed spending our time making tools to make the use case you describe work with multiple moodle installs. From a technical point of view it seems to me that the maximum flexibility comes with multiple installs managed with new tools to provide the multi-tenancy feature. The scope of what is required by a single tenant seems to be no different than a Moodle install and again from a technical point of view it seems we are introducing another 'layer' which is pretty much the same as Moodle installation.
          Hide
          Mary Evans added a comment - - edited

          If everyone was to upload a diagram of "their view" of a Moodle with Multi-Tenancy Capability each image would be different. So let's not get into the Design by Committee scenario PLEASE!

          http://en.wikipedia.org/wiki/Design_by_committee

          Show
          Mary Evans added a comment - - edited If everyone was to upload a diagram of "their view" of a Moodle with Multi-Tenancy Capability each image would be different. So let's not get into the Design by Committee scenario PLEASE! http://en.wikipedia.org/wiki/Design_by_committee
          Hide
          Ray Lawrence added a comment -

          To Dan:

          Really?

          One training provider
          20 clients as described above.

          20 moodle installs, 20 databases, 20 moodledatas + 1 global admin app

          or

          1 moodle install, 1 database, 1 moodledata

          Show
          Ray Lawrence added a comment - To Dan: Really? One training provider 20 clients as described above. 20 moodle installs, 20 databases, 20 moodledatas + 1 global admin app or 1 moodle install, 1 database, 1 moodledata
          Hide
          Ray Lawrence added a comment -

          Here's a diagram: not sure which stage we're at currently.

          http://www.businessballs.com/treeswing.htm

          Show
          Ray Lawrence added a comment - Here's a diagram: not sure which stage we're at currently. http://www.businessballs.com/treeswing.htm
          Hide
          Kyle Chase added a comment -

          I'm not sure my particular situation is common throughout the Moodle community, but I currently have over 200 campuses and close to 200,000 users in our legacy system, and we're looking at a potential Moodle implementation this year. Some campuses share content, some don't. Some campuses have custom branding, some don't. All log in through 1 of several portals, but are redirected to a single URL, and a IIS config breaks them out from there.

          Obviously the Multi-Tenancy functionality would be critical to our implementation so as you can imagine, I'm watching this particular discussion quite closely.

          Just wanted to share our volume with everyone, in case anyone was wondering about the larger volume potential.

          Thanks for your time.

          Show
          Kyle Chase added a comment - I'm not sure my particular situation is common throughout the Moodle community, but I currently have over 200 campuses and close to 200,000 users in our legacy system, and we're looking at a potential Moodle implementation this year. Some campuses share content, some don't. Some campuses have custom branding, some don't. All log in through 1 of several portals, but are redirected to a single URL, and a IIS config breaks them out from there. Obviously the Multi-Tenancy functionality would be critical to our implementation so as you can imagine, I'm watching this particular discussion quite closely. Just wanted to share our volume with everyone, in case anyone was wondering about the larger volume potential. Thanks for your time.
          Hide
          Juan Leyva added a comment - - edited

          One training provider
          20 clients as described above.
          20 moodle installs, 20 databases, 20 moodledatas + 1 global admin app
          or
          1 moodle install, 1 database, 1 moodledata

          I was suggesting 1 moodle install, 20 databases, 20 moodledata (or one moodledata with 20 subdirectories for each instance)

          If there is a control panel, and features for multiple upgrading I dont mind the number of databases.

          Please note, that a single database will not scale

          Ie. 50 tenants in the same database will create a 50000 records grade items/history table, this causes performance problems
          Using 50 differents databaes this will not happen, because we have 50 databases with a 1000 records grade items/history table

          Sometime ago we use a single Moodle installation with customizations for allowing tenants that caused us lot of performance problems

          Show
          Juan Leyva added a comment - - edited One training provider 20 clients as described above. 20 moodle installs, 20 databases, 20 moodledatas + 1 global admin app or 1 moodle install, 1 database, 1 moodledata I was suggesting 1 moodle install, 20 databases, 20 moodledata (or one moodledata with 20 subdirectories for each instance) If there is a control panel, and features for multiple upgrading I dont mind the number of databases. Please note, that a single database will not scale Ie. 50 tenants in the same database will create a 50000 records grade items/history table, this causes performance problems Using 50 differents databaes this will not happen, because we have 50 databases with a 1000 records grade items/history table Sometime ago we use a single Moodle installation with customizations for allowing tenants that caused us lot of performance problems
          Hide
          Juan Leyva added a comment -

          Luis, with a single codebase plugins will be installed for all the instances, but in every instance you can enable/disable modules, blocks, auths.. using the current administration feautres

          Plugins are present for all the isntances, but can be disabled

          Themes are more complicated, there is no way for disabling a theme once installed

          Show
          Juan Leyva added a comment - Luis, with a single codebase plugins will be installed for all the instances, but in every instance you can enable/disable modules, blocks, auths.. using the current administration feautres Plugins are present for all the isntances, but can be disabled Themes are more complicated, there is no way for disabling a theme once installed
          Hide
          Ray Lawrence added a comment -

          Juan, this themes issue is one that will have to be addressed. Tenant specific branding of their respective spaces is crucial.

          Show
          Ray Lawrence added a comment - Juan, this themes issue is one that will have to be addressed. Tenant specific branding of their respective spaces is crucial.
          Hide
          Mary Evans added a comment -
          Quote: Juan Layva Said
          "...Themes are more complicated, there is no way
          for disabling a theme once installed..."
          

          I don't think Themes are complicated at all, yes they are classed as 'plugins' but are very easy to disable, you just remove them from the theme directory.

          However if you want control over which themes are available then I am sure this could be added as a setting somewhere, over and above the options already in the admin's themes settings page.

          Show
          Mary Evans added a comment - Quote: Juan Layva Said "...Themes are more complicated, there is no way for disabling a theme once installed..." I don't think Themes are complicated at all, yes they are classed as 'plugins' but are very easy to disable, you just remove them from the theme directory. However if you want control over which themes are available then I am sure this could be added as a setting somewhere, over and above the options already in the admin's themes settings page.
          Hide
          Juan Leyva added a comment -

          Mary Evans said
          I don't think Themes are complicated at all, yes they are classed as 'plugins' but are very easy to disable, you just remove them from the theme directory.

          However if you want control over which themes are available then I am sure this could be added as a setting somewhere, over and above the options already in the admin's themes settings page.

          I was talking in the scenario of having a single base of code and multiple databases for every instance.
          Since themes are detected if they are present in the code and there is not a way to disable it (a logic disable in the database) installing a theme in a shared base of code means that this theme will be available for all the instances.
          Modules and blocks can be present in the code but disabled for every instance.

          I think it will be mandatory options for disabling themes (in a logic way, in database)

          Show
          Juan Leyva added a comment - Mary Evans said I don't think Themes are complicated at all, yes they are classed as 'plugins' but are very easy to disable, you just remove them from the theme directory. However if you want control over which themes are available then I am sure this could be added as a setting somewhere, over and above the options already in the admin's themes settings page. I was talking in the scenario of having a single base of code and multiple databases for every instance. Since themes are detected if they are present in the code and there is not a way to disable it (a logic disable in the database) installing a theme in a shared base of code means that this theme will be available for all the instances. Modules and blocks can be present in the code but disabled for every instance. I think it will be mandatory options for disabling themes (in a logic way, in database)
          Hide
          Richard Oelmann added a comment -

          Juan,
          The Theme Settings page has an allowable themes section - if this level of delegation to multi-tenants is enabled, then each tenant admin would be able to control their list of available themes. Alternatively, would it be possible to reserve this authority for the global admin - either way I think the mechanism is there to be developed.

          Richard

          Show
          Richard Oelmann added a comment - Juan, The Theme Settings page has an allowable themes section - if this level of delegation to multi-tenants is enabled, then each tenant admin would be able to control their list of available themes. Alternatively, would it be possible to reserve this authority for the global admin - either way I think the mechanism is there to be developed. Richard
          Hide
          Ricard Luquero added a comment -

          Our company is very interested in this topic. We must maintain multiple Moodle "versions" under a single code base just like Wordpress or similar. We will stay tuned to this issue with the hope that eventually this issue receives the approval to be developed.

          Show
          Ricard Luquero added a comment - Our company is very interested in this topic. We must maintain multiple Moodle "versions" under a single code base just like Wordpress or similar. We will stay tuned to this issue with the hope that eventually this issue receives the approval to be developed.
          Hide
          Ray Lawrence added a comment -

          Hi,

          We have some client meetings coming up where we'll need to re-visit this issue. What's the current HQ view on methodology, viability, schedule?

          Show
          Ray Lawrence added a comment - Hi, We have some client meetings coming up where we'll need to re-visit this issue. What's the current HQ view on methodology, viability, schedule?
          Hide
          Juan Leyva added a comment -

          It seems it was deleted in the 2.3 Roadmap http://docs.moodle.org/dev/Roadmap

          Show
          Juan Leyva added a comment - It seems it was deleted in the 2.3 Roadmap http://docs.moodle.org/dev/Roadmap
          Hide
          Alex Büchner added a comment -

          I believe that this project has been cancelled ("postponed indefinitely") by HQ due to its complexity. Is this correct?

          Show
          Alex Büchner added a comment - I believe that this project has been cancelled ("postponed indefinitely") by HQ due to its complexity. Is this correct?
          Hide
          Alex Büchner added a comment -

          I believe that this project has been cancelled ("postponed indefinitely") by HQ due to its complexity. Is this correct?

          Show
          Alex Büchner added a comment - I believe that this project has been cancelled ("postponed indefinitely") by HQ due to its complexity. Is this correct?
          Hide
          Martin Dougiamas added a comment -

          We started this project using this approach (http://docs.moodle.org/dev/Multitenant_support) during the 2.2 DEV cycle because:

          • it addressed 90% of what people were asking for wrt multi-site hosting
          • it seemed simple without much impact on Moodle for other users
          • the original estimate was expressed in "weeks".

          Unfortunately, during 2011 it became apparent that:

          It's unfortunate, but I think the responsible thing for me to protect Moodle is to cancel that approach. At least we did get some good improvements to accesslib out of it, and some clean up in other areas of Moodle.

          I'm not closing this bug yet though, because we obviously still need to solve the problem.

          I agree with those saying a much better approach would be to focus on something that is mostly external to Moodle itself, that can manage multiple whole sites and databases efficiently, and deal with users that cross those sites.

          Dan has just started at HQ, and I'd like him to be working on this for 2.4. We need to be starting to collect ideas and requirements now for a detailed spec with this approach.

          Show
          Martin Dougiamas added a comment - We started this project using this approach ( http://docs.moodle.org/dev/Multitenant_support ) during the 2.2 DEV cycle because: it addressed 90% of what people were asking for wrt multi-site hosting it seemed simple without much impact on Moodle for other users the original estimate was expressed in "weeks". Unfortunately, during 2011 it became apparent that: it addressed less than 90% of what people wanted wrt multi-site hosting, it was a complex issue and had the potential to create regressions all over Moodle the estimate was revised by Petr to be a lot longer ( https://github.com/skodak/moodle/blob/wip_multitenant_3-57/multitenants_wip.md ) It's unfortunate, but I think the responsible thing for me to protect Moodle is to cancel that approach. At least we did get some good improvements to accesslib out of it, and some clean up in other areas of Moodle. I'm not closing this bug yet though, because we obviously still need to solve the problem. I agree with those saying a much better approach would be to focus on something that is mostly external to Moodle itself, that can manage multiple whole sites and databases efficiently, and deal with users that cross those sites. Dan has just started at HQ, and I'd like him to be working on this for 2.4. We need to be starting to collect ideas and requirements now for a detailed spec with this approach.
          Hide
          Ray Lawrence added a comment -

          I'd like to thank those at HQ who have been working to try to implement this and also express my disappointment that this can't be achieved in the short term.

          Although I've made the point earlier in the discussions above, I'd like to confirm that this continues to be a much desired enhancement across the board i.e. it's not a "corporate" requirement.

          I await Dan's proposal with interest, there's plenty of comment in this issue to kick that off.

          I think it would be useful if others could comment on whether their experience reflects mine: the improvement desired by Moodle users is the ability to better manage specific and separate user populations on a single site rather than tools to manage them on separate multiple Moodle sites.

          Show
          Ray Lawrence added a comment - I'd like to thank those at HQ who have been working to try to implement this and also express my disappointment that this can't be achieved in the short term. Although I've made the point earlier in the discussions above, I'd like to confirm that this continues to be a much desired enhancement across the board i.e. it's not a "corporate" requirement. I await Dan's proposal with interest, there's plenty of comment in this issue to kick that off. I think it would be useful if others could comment on whether their experience reflects mine: the improvement desired by Moodle users is the ability to better manage specific and separate user populations on a single site rather than tools to manage them on separate multiple Moodle sites.
          Hide
          gavin henrick added a comment -

          I wonder if there are two different use cases in this page (or maybe more):

          1. fully isolating cohorts so that
          a) they if separate cohorts selected that they cannot see if other (taking the separate groups site-wide)
          b) implementing sub-cohorts
          c) having different membership options in the cohort (manager, or member)
          d) auto-create groups/groupings for the cohort in a course when it is enrolled in it

          Yes, somewhat like Cluster/Sets of ELIS but this is in one site, where one trainer facilitator can manage a course but have 3 cohorts in it which can only see each other in participant lists etc..

          2. SaaS whitelabelling of the Moodle site

          • full site settings (theme, module choice, etc) dependant on a user account

          I could be over simplifying, but I think the above discussion perhaps mixed or muxed the two concepts bringing the extra complexity it perhaps does not need.

          The first concept is something that would have use in academia corporate.

          Would it be therefore possible to look at two different solutions for the above ideas.

          Show
          gavin henrick added a comment - I wonder if there are two different use cases in this page (or maybe more): 1. fully isolating cohorts so that a) they if separate cohorts selected that they cannot see if other (taking the separate groups site-wide) b) implementing sub-cohorts c) having different membership options in the cohort (manager, or member) d) auto-create groups/groupings for the cohort in a course when it is enrolled in it Yes, somewhat like Cluster/Sets of ELIS but this is in one site, where one trainer facilitator can manage a course but have 3 cohorts in it which can only see each other in participant lists etc.. 2. SaaS whitelabelling of the Moodle site full site settings (theme, module choice, etc) dependant on a user account I could be over simplifying, but I think the above discussion perhaps mixed or muxed the two concepts bringing the extra complexity it perhaps does not need. The first concept is something that would have use in academia corporate. Would it be therefore possible to look at two different solutions for the above ideas.
          Hide
          Dan Poltawski added a comment -

          Yes please do help me understand the use cases better as discussed earlier up the thread.

          Though regarding Ray's request - I would really like to understand better why it has to be on a single site.

          Show
          Dan Poltawski added a comment - Yes please do help me understand the use cases better as discussed earlier up the thread. Though regarding Ray's request - I would really like to understand better why it has to be on a single site.
          Hide
          Wesley Janik added a comment -

          The use case I'm trying to solve looks like the following: imagine a department run by a single person (department head), having two instructors, and six students. This department has courses created and managed by the department head, and utilized by the instructors.

          The department head has the authority to assign students to each instructor. The instructors have authority over their students (e.g. they can report their students' course progress, assign courses to the students, etc.). The department head has the authority to report on the progress of all students in the department, but the instructors have no knowledge of the other instructor's students.

          More specifically, instructor A has students 1, 2, and 3, and instructor B has students 4, 5, and 6. The department head can view the progress of students 1, 2, 3, 4, 5, and 6. Instructor A can view the progress of students 1, 2, and 3, and instructor B can view the progress of students 4, 5, and 6. Instructor A not only cannot report on students 4, 5, and 6, but isn't allowed to know they even exist (let alone fall under the authority of instructor B). Similarly, instructor B isn't allowed to know of the existence of students 1, 2, and 3.

          As an added bonus, it would be nice if the department head could make courses visible and available to only instructor A. Similarly, instructor B could create a course for their students (4, 5, and 6) that would not be visible/available to instructor A.

          Hopefully I'm not rambling here... The content, reporting, and users are all part of one entity, but need to be subdivided such that silos are created for the students.

          Show
          Wesley Janik added a comment - The use case I'm trying to solve looks like the following: imagine a department run by a single person (department head), having two instructors, and six students. This department has courses created and managed by the department head, and utilized by the instructors. The department head has the authority to assign students to each instructor. The instructors have authority over their students (e.g. they can report their students' course progress, assign courses to the students, etc.). The department head has the authority to report on the progress of all students in the department, but the instructors have no knowledge of the other instructor's students. More specifically, instructor A has students 1, 2, and 3, and instructor B has students 4, 5, and 6. The department head can view the progress of students 1, 2, 3, 4, 5, and 6. Instructor A can view the progress of students 1, 2, and 3, and instructor B can view the progress of students 4, 5, and 6. Instructor A not only cannot report on students 4, 5, and 6, but isn't allowed to know they even exist (let alone fall under the authority of instructor B). Similarly, instructor B isn't allowed to know of the existence of students 1, 2, and 3. As an added bonus, it would be nice if the department head could make courses visible and available to only instructor A. Similarly, instructor B could create a course for their students (4, 5, and 6) that would not be visible/available to instructor A. Hopefully I'm not rambling here... The content, reporting, and users are all part of one entity, but need to be subdivided such that silos are created for the students.
          Hide
          gavin henrick added a comment -

          Has to be one instance for

          • ease of management for the site admin
          • ease of course management (if you provide a range of courses that people may take you don't want to have to duplicate it all which would impact replicating changes, having to gather together data from them all for detail cross-cohort analysis)
          • ease of user management (You may have people in multiple cohorts, so their both of their cohort admin needs to be able to report on them, could be a school, and faculty, hierarchial, or in a corporate, could be sales and HR, or development and marketing.. which may need to report on different suites of courses etc..)

          Hence why extending core abilities like cohort to include some of the ELIS type user set structures / reporting makes sense, but it does need to have the separation aspect to enable participations block, messaging, enrolment all be filtered.

          Show
          gavin henrick added a comment - Has to be one instance for ease of management for the site admin ease of course management (if you provide a range of courses that people may take you don't want to have to duplicate it all which would impact replicating changes, having to gather together data from them all for detail cross-cohort analysis) ease of user management (You may have people in multiple cohorts, so their both of their cohort admin needs to be able to report on them, could be a school, and faculty, hierarchial, or in a corporate, could be sales and HR, or development and marketing.. which may need to report on different suites of courses etc..) Hence why extending core abilities like cohort to include some of the ELIS type user set structures / reporting makes sense, but it does need to have the separation aspect to enable participations block, messaging, enrolment all be filtered.
          Hide
          Martin Dougiamas added a comment - - edited

          I don't think "ease" means it has to be a single instance ... The point of an outer layer is exactly to handle those user/course management details for you.

          What you're saying about cohorts and keeping them "isolated" is basically the approach already tried and it's just too messy.

          Show
          Martin Dougiamas added a comment - - edited I don't think "ease" means it has to be a single instance ... The point of an outer layer is exactly to handle those user/course management details for you. What you're saying about cohorts and keeping them "isolated" is basically the approach already tried and it's just too messy.
          Hide
          gavin henrick added a comment -

          Sorry, I thought it had been trying to add extra aspects as well, rather than just filtering the users.

          I see the benefit of having a system which manages multiple virtual or real installs though

          a management interface that enables
          a) create new client/department/set of users
          b) configure their admin account
          c) add user structures
          d) select what initial courses / categories of courses should be added to the site (and perhaps synchronised)
          e) produce reporting at personal level, and user structure levels across the instance
          f) apply a theme for it / enable/disable plugins and so on.

          If it removes the technical complications, then it does cater for quite a few of the use cases be it intra department or one organisation managing multiple clients.

          However how can this facilitate

          • a course author at a top level reporting on one course across multiple sites, without building a major data silo centrally which duplicates the dat
          • adding a new activity which them gets added to all
          • editing/fixing a resource/activity which is replicated to all
          • being in a forum that you are facilitating but now that forum exists in X sites, and you will need to log into each one to reply to the questions there, rather than logging into one and knowing the isolated cohorts in that forum are isolated groups and can jump around to view them, etc.
          • having to grade in one place vs grade on multiple sites

          Having re-read the discussion and wiki page, would think the suggesiton of the improvement of cohort to be like ELIS user sets but adding logic on each potential touch point to isolate would not require most of of aspects that had been proposed, sorry if I am not explaining well.

          I think one key is that the users are not always in distinct silos, that is just one potential use case of having a provider sell courses to a client, rather than one very large organisation which has multiple vertical and horizontal group structures so that someone can be in many.

          Company wise
          I can be in an Ireland cohort
          I can be in a product X cohort
          I can be in a sales cohort
          As a user i exist once, but in 3 groups, so that I can converse

          But yes, perhaps this is just isolating a full site-wide, multi layer groups rather than a pure multi-tenancy as described by some.

          Show
          gavin henrick added a comment - Sorry, I thought it had been trying to add extra aspects as well, rather than just filtering the users. I see the benefit of having a system which manages multiple virtual or real installs though a management interface that enables a) create new client/department/set of users b) configure their admin account c) add user structures d) select what initial courses / categories of courses should be added to the site (and perhaps synchronised) e) produce reporting at personal level, and user structure levels across the instance f) apply a theme for it / enable/disable plugins and so on. If it removes the technical complications, then it does cater for quite a few of the use cases be it intra department or one organisation managing multiple clients. However how can this facilitate a course author at a top level reporting on one course across multiple sites, without building a major data silo centrally which duplicates the dat adding a new activity which them gets added to all editing/fixing a resource/activity which is replicated to all being in a forum that you are facilitating but now that forum exists in X sites, and you will need to log into each one to reply to the questions there, rather than logging into one and knowing the isolated cohorts in that forum are isolated groups and can jump around to view them, etc. having to grade in one place vs grade on multiple sites Having re-read the discussion and wiki page, would think the suggesiton of the improvement of cohort to be like ELIS user sets but adding logic on each potential touch point to isolate would not require most of of aspects that had been proposed, sorry if I am not explaining well. I think one key is that the users are not always in distinct silos, that is just one potential use case of having a provider sell courses to a client, rather than one very large organisation which has multiple vertical and horizontal group structures so that someone can be in many. Company wise I can be in an Ireland cohort I can be in a product X cohort I can be in a sales cohort As a user i exist once, but in 3 groups, so that I can converse But yes, perhaps this is just isolating a full site-wide, multi layer groups rather than a pure multi-tenancy as described by some.
          Hide
          vijay nair added a comment - - edited

          Hi Gavin,

          I would like answer the above bullet points you have raised by using an example of another Corporate LMS system that actually facilitates these features.

          So the architecture used for having this added is a "Control Panel" available in the front end of the site. Something that "global" site Administrators are able to easily add.

          1) a course author at a top level reporting on one course across multiple sites, without building a major data silo centrally which duplicates the dat

          {There is no need to worry about this as the lms would have a separate section called courses or something alike that lets you add courses centrally to each tenant site or let you select multiple tenants using the control panel}

          2) adding a new activity which them gets added to all -

          {Again the above control panel would let you select which tenant site requires what activities to be added. This should be available in 2 areas- 1) while creating the tenant site - you select which activities to be added to the site, 2) After the tenant site is created you still have the feature to add or remove or disable/ enable more activities/ resources to the existing site}

          3) editing/fixing a resource/activity which is replicated to all

          {While editing a resource, the option to do this will be split into 2 parts - 1) Editing a resource from within the tenant site or editing a resource - centrally. If editing centrally then it takes effect on all sites, but to target only ons site, then do it within the tenant site}

          4) being in a forum that you are facilitating but now that forum exists in X sites, and you will need to log into each one to reply to the questions there, rather than logging into one and knowing the isolated cohorts in that forum are isolated groups and can jump around to view them, etc.

          {TO take care of this issue, the lms must have the email system must be enabled. So every time a new post or discussion is open, you get an email alert with a link that directs you to that post/ discussion - which you can then filter it by adding rules in your outlook email. The alternative is for the lms system to log forums and have separate page to show a tick or any symbol besides each forum that has a new post/discussion }

          5) having to grade in one place vs grade on multiple sites

          {Grading or reporting of any kind again can be done using my first point - the control panel. So again 2 features must be available. a) grading within the tenant site b) Grading centrally which would have a collective list of all the user accounts and their associated scores.}

          I hope my points would get the developers some ideas for implementing this strategy within the moodle multi layered / multi-tenant approach.

          Vijay

          Show
          vijay nair added a comment - - edited Hi Gavin, I would like answer the above bullet points you have raised by using an example of another Corporate LMS system that actually facilitates these features. So the architecture used for having this added is a "Control Panel" available in the front end of the site. Something that "global" site Administrators are able to easily add. 1) a course author at a top level reporting on one course across multiple sites, without building a major data silo centrally which duplicates the dat {There is no need to worry about this as the lms would have a separate section called courses or something alike that lets you add courses centrally to each tenant site or let you select multiple tenants using the control panel} 2) adding a new activity which them gets added to all - {Again the above control panel would let you select which tenant site requires what activities to be added. This should be available in 2 areas- 1) while creating the tenant site - you select which activities to be added to the site, 2) After the tenant site is created you still have the feature to add or remove or disable/ enable more activities/ resources to the existing site} 3) editing/fixing a resource/activity which is replicated to all {While editing a resource, the option to do this will be split into 2 parts - 1) Editing a resource from within the tenant site or editing a resource - centrally. If editing centrally then it takes effect on all sites, but to target only ons site, then do it within the tenant site} 4) being in a forum that you are facilitating but now that forum exists in X sites, and you will need to log into each one to reply to the questions there, rather than logging into one and knowing the isolated cohorts in that forum are isolated groups and can jump around to view them, etc. {TO take care of this issue, the lms must have the email system must be enabled. So every time a new post or discussion is open, you get an email alert with a link that directs you to that post/ discussion - which you can then filter it by adding rules in your outlook email. The alternative is for the lms system to log forums and have separate page to show a tick or any symbol besides each forum that has a new post/discussion } 5) having to grade in one place vs grade on multiple sites {Grading or reporting of any kind again can be done using my first point - the control panel. So again 2 features must be available. a) grading within the tenant site b) Grading centrally which would have a collective list of all the user accounts and their associated scores.} I hope my points would get the developers some ideas for implementing this strategy within the moodle multi layered / multi-tenant approach. Vijay
          Hide
          Ray Lawrence added a comment -

          To Dan:

          Organisations look to implement a single LMS/VLE/CMS.

          Where they have a requirement to cater for a discrete set of users in the ways that have been outlined above they would like to be able to do this without having to implement a new LMS/VLE/CMS for each set of users. Establishing and administering multiple moodle sites is more expensive and less convenient than establishing and administering a single site.

          Where each set of users needs a significantly different configuration IMO multiple sites are the way to go, we should accept that and not try to offer a single site solution for every possible configuration combination.

          Typically, each set of users requires a similar configuration and site operators are bewildered as to why they cannot separate these set at system level so that:

          • User management i.e. creation, deletion, enrolments for a set can be delegated to a "Manager" in that set without the ability to see all other users on the site
          • Users in the set are automatically allocated to a default theme for the set
          • There is the option for a set specific landing page
          • Communications can only be between users within the same set
          • Reports (if/when Moodle has this facility in core) may only be generated for and viewed by users in a set. Of course system admins needs to be able to do/see all of this.

          I hope that helps clarify why I'm like a dog with a bone with this one. If not feel free to seek further clarification.

          It would also help move the discussion on if you could make the case for the multiple site approach you are advocating. Beyond this being simpler to implement (which isn't a benefit for end users), what are the advantages you anticipate?

          Show
          Ray Lawrence added a comment - To Dan: Organisations look to implement a single LMS/VLE/CMS. Where they have a requirement to cater for a discrete set of users in the ways that have been outlined above they would like to be able to do this without having to implement a new LMS/VLE/CMS for each set of users. Establishing and administering multiple moodle sites is more expensive and less convenient than establishing and administering a single site. Where each set of users needs a significantly different configuration IMO multiple sites are the way to go, we should accept that and not try to offer a single site solution for every possible configuration combination. Typically, each set of users requires a similar configuration and site operators are bewildered as to why they cannot separate these set at system level so that: User management i.e. creation, deletion, enrolments for a set can be delegated to a "Manager" in that set without the ability to see all other users on the site Users in the set are automatically allocated to a default theme for the set There is the option for a set specific landing page Communications can only be between users within the same set Reports (if/when Moodle has this facility in core) may only be generated for and viewed by users in a set. Of course system admins needs to be able to do/see all of this. I hope that helps clarify why I'm like a dog with a bone with this one. If not feel free to seek further clarification. It would also help move the discussion on if you could make the case for the multiple site approach you are advocating. Beyond this being simpler to implement (which isn't a benefit for end users), what are the advantages you anticipate?
          Hide
          Ray Lawrence added a comment -

          From Gavin:

          "Company wise
          I can be in an Ireland cohort
          I can be in a product X cohort
          I can be in a sales cohort
          As a user i exist once, but in 3 groups, so that I can converse"

          Yes, I've considered that this would be an issue and that the compromise would be that cross-set communication just wouldn't be possible. Then I thought about the fact that admins can already manage this sort of thing i.e. email and blog visibility and wondered why this can't be scaled to other communication options.

          Show
          Ray Lawrence added a comment - From Gavin: "Company wise I can be in an Ireland cohort I can be in a product X cohort I can be in a sales cohort As a user i exist once, but in 3 groups, so that I can converse" Yes, I've considered that this would be an issue and that the compromise would be that cross-set communication just wouldn't be possible. Then I thought about the fact that admins can already manage this sort of thing i.e. email and blog visibility and wondered why this can't be scaled to other communication options.
          Hide
          Andrea Bicciolo added a comment - - edited

          Although there are possible usage scenarios for a multi-Moodle approach with a single, central admin tool, to our knowledge, as Ray already pointed out, the vast majority of organizations looks to implement a single LMS.

          I understand the cons and possible regressions of adding the new tenant context, however the need of isolating set of users is much requested and should be addressed, maybe a possibility already mentioned in this thread is expanding the concept of cohort.

          At a very bottom line better isolating users in sets each with separate course catalogs, delegating a "Manager" of a given users set to edit users and courses, and reporting accordingly would be a good starting point (again, I think Ray already summarized it well).

          There are also other things to consider,while the complete isolation of users may address well some usage scenarios (such as the course vendor serving different clients), in many organizations users may belongs to different user sets. Also, during their processional life inside organizations, users may change their users set. I think Gavin pointed out this, both are scenarios that should be taken into account allowing some sort of track record of attended courses. If the compromise to obtain this is the absence of cross-set communication anyway (to satisfy complete user set isolation scenario), I think this compromise is completely acceptable.

          Show
          Andrea Bicciolo added a comment - - edited Although there are possible usage scenarios for a multi-Moodle approach with a single, central admin tool, to our knowledge, as Ray already pointed out, the vast majority of organizations looks to implement a single LMS. I understand the cons and possible regressions of adding the new tenant context, however the need of isolating set of users is much requested and should be addressed, maybe a possibility already mentioned in this thread is expanding the concept of cohort. At a very bottom line better isolating users in sets each with separate course catalogs, delegating a "Manager" of a given users set to edit users and courses, and reporting accordingly would be a good starting point (again, I think Ray already summarized it well). There are also other things to consider,while the complete isolation of users may address well some usage scenarios (such as the course vendor serving different clients), in many organizations users may belongs to different user sets. Also, during their processional life inside organizations, users may change their users set. I think Gavin pointed out this, both are scenarios that should be taken into account allowing some sort of track record of attended courses. If the compromise to obtain this is the absence of cross-set communication anyway (to satisfy complete user set isolation scenario), I think this compromise is completely acceptable.
          Hide
          Martin Dougiamas added a comment -

          I think the solution looks like this:

          1. one install of Moodle code.
          2. a special multi-site config.php that can select sites depending on URL.
          3. one database per site (or one database, but each site has a unique prefix).
          4. one dirroot per site (or one dirroot, but each site has a subdirectory).
          5. new superadmin "wrapper" code to manage the multiple Moodle sites from a bird's eye perspective.
            • It would handle upgrades to all sites at once.
            • It would allow users to be synched or copied across sites.
            • It could handle SSO via Oauth2
            • It can do cross-site reports.
            • It can even rewrite the special config.php (to add/remove/change sites).

          This whole multi-site system essentially looks and acts like one LMS, but we don't need to mess with all the code in Moodle that the tenant code had to.

          Show
          Martin Dougiamas added a comment - I think the solution looks like this: one install of Moodle code. a special multi-site config.php that can select sites depending on URL. one database per site (or one database, but each site has a unique prefix). one dirroot per site (or one dirroot, but each site has a subdirectory). new superadmin "wrapper" code to manage the multiple Moodle sites from a bird's eye perspective. It would handle upgrades to all sites at once. It would allow users to be synched or copied across sites. It could handle SSO via Oauth2 It can do cross-site reports. It can even rewrite the special config.php (to add/remove/change sites). This whole multi-site system essentially looks and acts like one LMS, but we don't need to mess with all the code in Moodle that the tenant code had to.
          Hide
          Dan Poltawski added a comment -

          @Ray

          It would also help move the discussion on if you could make the case for the multiple site approach you are advocating. Beyond this being simpler to implement (which isn't a benefit for end users), what are the advantages you anticipate?

          I accept I am coming at this purely from a technical point of view - because the successful implementation of this sort of separation in a single site environment is really quite significant and I became involved in this issue because it raised technical alarm bells in my head. It changes the fundamental technical design of Moodle now and will require most of the core to be changed and I would expect.. third party plugins.

          So having written that, I guess you could say backwards compatibility with third party plugins is a major end user advantage of not going down this route. Also with this sort of change there is a real risk of it being a 95% solution (i.e. 5% of places slip through the cracks and don't support the separation - making the separation kinda useless) - just look at some poor support of 'separate groups' for examples of that problem.

          BUT - the reason I am asking the questions is because I think it is achievable that we make the multi-site approach just as easy to use from an end user point of view as your vision of separation in a single site. So I want to gain an insight into the challenges and see if we can solve them.

          Show
          Dan Poltawski added a comment - @Ray It would also help move the discussion on if you could make the case for the multiple site approach you are advocating. Beyond this being simpler to implement (which isn't a benefit for end users), what are the advantages you anticipate? I accept I am coming at this purely from a technical point of view - because the successful implementation of this sort of separation in a single site environment is really quite significant and I became involved in this issue because it raised technical alarm bells in my head. It changes the fundamental technical design of Moodle now and will require most of the core to be changed and I would expect.. third party plugins. So having written that, I guess you could say backwards compatibility with third party plugins is a major end user advantage of not going down this route. Also with this sort of change there is a real risk of it being a 95% solution (i.e. 5% of places slip through the cracks and don't support the separation - making the separation kinda useless) - just look at some poor support of 'separate groups' for examples of that problem. BUT - the reason I am asking the questions is because I think it is achievable that we make the multi-site approach just as easy to use from an end user point of view as your vision of separation in a single site. So I want to gain an insight into the challenges and see if we can solve them.
          Hide
          Ray Lawrence added a comment -

          @Dan

          Complexity: Accepted.
          Plugin backwards compatibility: OK, but that's been set aside before.
          5% issue: Agreed
          As easy as a single site: Yup

          Martin's proposal:

          Would the system admin login to Moodle or a separate admin console?

          Overall: The multi-site option is being considered from a technical point of view in this discussion i.e. that in effect it's technically multiple instances.

          If we consider Martin's proposal 27/Feb/12 5:18 PM and start thinking about this in end user terms and call it a "Multi-client" set up that makes it feel quite different. Do you agree?

          Show
          Ray Lawrence added a comment - @Dan Complexity: Accepted. Plugin backwards compatibility: OK, but that's been set aside before. 5% issue: Agreed As easy as a single site: Yup Martin's proposal: Would the system admin login to Moodle or a separate admin console? Overall: The multi-site option is being considered from a technical point of view in this discussion i.e. that in effect it's technically multiple instances. If we consider Martin's proposal 27/Feb/12 5:18 PM and start thinking about this in end user terms and call it a "Multi-client" set up that makes it feel quite different. Do you agree?
          Hide
          Martin Dougiamas added a comment -

          I think the system admin would log in to http://anysiteurlinthesystem/console, for example. It could have a login completely outside of Moodle accounts.

          Multi-client, multi-tenant, multi-site - whatever floats one's boat, it's the same thing.

          Show
          Martin Dougiamas added a comment - I think the system admin would log in to http://anysiteurlinthesystem/console , for example. It could have a login completely outside of Moodle accounts. Multi-client, multi-tenant, multi-site - whatever floats one's boat, it's the same thing.
          Hide
          Ray Lawrence added a comment -

          OK.

          OK, it's the same thing under the bonnet but names and perceptions are important here:

          Multi-site: "To achieve that with Moodle we need to set you up with multi-site configuration." "Oh, I only want one site really." "That's OK, it's sort of like one site but you just see...." "Sounds complicated. Yawn"

          Multi-client: "To achieve that for your Moodle site we'll use the multi-client option" "Great"

          With apologies for labouring the point....

          Show
          Ray Lawrence added a comment - OK. OK, it's the same thing under the bonnet but names and perceptions are important here: Multi-site: "To achieve that with Moodle we need to set you up with multi-site configuration." "Oh, I only want one site really." "That's OK, it's sort of like one site but you just see...." "Sounds complicated. Yawn" Multi-client: "To achieve that for your Moodle site we'll use the multi-client option" "Great" With apologies for labouring the point....
          Hide
          Wesley Janik added a comment -

          Unless I misunderstand the proposal, I think the "multi-site manager" approach creates a disjointed experience for the student. This requires the student to know the URL of every silo/site they are a part of, and potentially move from one to the other in a single session. Further, the instructors would need to communicate separate URLs for each silo. Ideally, I think the student would like to log in once and see all that is available to them.

          This creates a substantial problem for LMS deployed in a corporate environment. If users are managed at a department level every department would require their own LMS URL, rather than one utilized across the enterprise. If an employee changes organizations, it becomes a cumbersome exercise to move the user and communicate the new org's URL.

          Show
          Wesley Janik added a comment - Unless I misunderstand the proposal, I think the "multi-site manager" approach creates a disjointed experience for the student. This requires the student to know the URL of every silo/site they are a part of, and potentially move from one to the other in a single session. Further, the instructors would need to communicate separate URLs for each silo. Ideally, I think the student would like to log in once and see all that is available to them. This creates a substantial problem for LMS deployed in a corporate environment. If users are managed at a department level every department would require their own LMS URL, rather than one utilized across the enterprise. If an employee changes organizations, it becomes a cumbersome exercise to move the user and communicate the new org's URL.
          Hide
          Martin Dougiamas added a comment - - edited

          Wesley, I think what you want is one normal Moodle site for the enterprise. If you want users moving seamlessly between departments and having courses in multiple departments then surely they aren't really just managed by one department, are they? In that case why not just have one site, one account per user, one category per department, and use the functionality we have already to just show the user just the courses they are enrolled in (regardless of course category)?

          The main need for a new multi-anything here, as I understand it, is REAL separateness and different urls. In the cases where users migrate between instances, we can have superadmin tools in the 'wrapper' to copy/migrate user accounts.

          However, even with the totally seperate scenario, I guess we could have a general user interface in the wrapper that shows all the sites your account is linked with, and perhaps consolidates the courses in one list. I'm seeing the wrapper as a shell that supports plugins, so that we could have developers writing all kinds of additional functionality like this.

          Show
          Martin Dougiamas added a comment - - edited Wesley, I think what you want is one normal Moodle site for the enterprise. If you want users moving seamlessly between departments and having courses in multiple departments then surely they aren't really just managed by one department, are they? In that case why not just have one site, one account per user, one category per department, and use the functionality we have already to just show the user just the courses they are enrolled in (regardless of course category)? The main need for a new multi-anything here, as I understand it, is REAL separateness and different urls. In the cases where users migrate between instances, we can have superadmin tools in the 'wrapper' to copy/migrate user accounts. However, even with the totally seperate scenario, I guess we could have a general user interface in the wrapper that shows all the sites your account is linked with, and perhaps consolidates the courses in one list. I'm seeing the wrapper as a shell that supports plugins, so that we could have developers writing all kinds of additional functionality like this.
          Hide
          Martin Dougiamas added a comment -

          Ray, maybe it's a tech/biz jargon problem but multi-client to me sounds like there's a server somewhere that they are communicating with. Does the tenant terminology still work for you?

          Show
          Martin Dougiamas added a comment - Ray, maybe it's a tech/biz jargon problem but multi-client to me sounds like there's a server somewhere that they are communicating with. Does the tenant terminology still work for you?
          Hide
          Andrea Bicciolo added a comment - - edited

          Martin, about the comment coming from Wesley I think the usage scenario is difficult to fully address with a single Moodle site. User base is currently not divided into user sets, so a role can manage profiles in a "all or none" fashion, while the need to address is to manage only the given user sets (add, edit, update...). Also, course categories could be a way to isolate users but this not work for isolating course catalogs, as users has access to the complete course catalog regardless the category where their courses are placed, while differentiating course catalogs according to user set is another requirement to address. In several environments where separate users set is needed is needed to let people see the course where they are enrolled from a department role as well as courses they could attend and self-enroll, the latter differentiated per user sets.

          Show
          Andrea Bicciolo added a comment - - edited Martin, about the comment coming from Wesley I think the usage scenario is difficult to fully address with a single Moodle site. User base is currently not divided into user sets, so a role can manage profiles in a "all or none" fashion, while the need to address is to manage only the given user sets (add, edit, update...). Also, course categories could be a way to isolate users but this not work for isolating course catalogs, as users has access to the complete course catalog regardless the category where their courses are placed, while differentiating course catalogs according to user set is another requirement to address. In several environments where separate users set is needed is needed to let people see the course where they are enrolled from a department role as well as courses they could attend and self-enroll, the latter differentiated per user sets.
          Hide
          Ray Lawrence added a comment -

          @Wesley

          I think this may be a step too far. They are either in one set or another. If they are to access via a single url and be able to move or be moved at will to another set of users that sounds like Moodle as we know it now. The departmental shift potential that you mention doesn't seem to warrant the separation that's being advocated here.

          It appears to me that this would be better served by a hierarchical user management facility that could be used across the whole site where there is no segmentation or configured as required within a client/tenant. This is slightly out of scope of this discussion but is another significant gap. Could this be in the SuperAdminConsole too so that core Moodle doesn't need to be torn apart? There are already Moodle based solutions developed for this out there... who fancies offering up their code?

          Show
          Ray Lawrence added a comment - @Wesley I think this may be a step too far. They are either in one set or another. If they are to access via a single url and be able to move or be moved at will to another set of users that sounds like Moodle as we know it now. The departmental shift potential that you mention doesn't seem to warrant the separation that's being advocated here. It appears to me that this would be better served by a hierarchical user management facility that could be used across the whole site where there is no segmentation or configured as required within a client/tenant. This is slightly out of scope of this discussion but is another significant gap. Could this be in the SuperAdminConsole too so that core Moodle doesn't need to be torn apart? There are already Moodle based solutions developed for this out there... who fancies offering up their code?
          Hide
          Ray Lawrence added a comment -

          @Martin

          Yes, that still works for me. Almost anything other than multi-sites. Despite what is happening on the server it needs to be presented in a joined up, seemingly uncomplicated manner and not in way that implies a kludge.

          Show
          Ray Lawrence added a comment - @Martin Yes, that still works for me. Almost anything other than multi-sites. Despite what is happening on the server it needs to be presented in a joined up, seemingly uncomplicated manner and not in way that implies a kludge.
          Hide
          Wesley Janik added a comment -

          Andrea is correct. The point here is managers need their access restricted to only their users. They are not allowed to know other users exist, and they cannot inspect the other user's progress (see my earlier comment with instructors A & B).

          Ray may be correct that this isn't truly "multi-tenant," but it's the primary use case I'm after - the ability to separate users and restrict access to both the user's existence and LMS (course) state. The student is still a single person belonging to the same larger entity as the student's instructor (manager), but the instructor's (manager's) perspective must be restricted to only a subset of all users. The manager's manager should be allowed access to all users in their subtree.

          Show
          Wesley Janik added a comment - Andrea is correct. The point here is managers need their access restricted to only their users. They are not allowed to know other users exist, and they cannot inspect the other user's progress (see my earlier comment with instructors A & B). Ray may be correct that this isn't truly "multi-tenant," but it's the primary use case I'm after - the ability to separate users and restrict access to both the user's existence and LMS (course) state. The student is still a single person belonging to the same larger entity as the student's instructor (manager), but the instructor's (manager's) perspective must be restricted to only a subset of all users. The manager's manager should be allowed access to all users in their subtree.
          Hide
          Ray Lawrence added a comment -

          Yes, so this is departmental access? This would benefit from a hierarchical structure as mentioned above.

          Org A

          All employees

          • Div. North
            --+ Course 1
            --+ Course 2
          • Div. South
            --+ Course 3
            --+ Course 4

          Org B

          All employees

          • Div. East
            --+ Course 10
            --+ Course 20
          • Div. West
            --+ Course 30
            --+ Course 40

          Manager in Div. North should have access to course 1 & 2 but not 3 & 4 (Div. South). I see these as the departments you mentioned. They are in the same tenant.

          Users in Org. A and B are totally separated. If user leaves Org A and joins Org B s/he needs a new account on the site for use in the Org B tenant.

          Show
          Ray Lawrence added a comment - Yes, so this is departmental access? This would benefit from a hierarchical structure as mentioned above. Org A All employees Div. North --+ Course 1 --+ Course 2 Div. South --+ Course 3 --+ Course 4 Org B All employees Div. East --+ Course 10 --+ Course 20 Div. West --+ Course 30 --+ Course 40 Manager in Div. North should have access to course 1 & 2 but not 3 & 4 (Div. South). I see these as the departments you mentioned. They are in the same tenant. Users in Org. A and B are totally separated. If user leaves Org A and joins Org B s/he needs a new account on the site for use in the Org B tenant.
          Hide
          Ray Lawrence added a comment -

          A quick thought on self-registration, each tenant must have a distinct url (supersite.com/org-a ?) otherwise self-registration can't be a possibility. If the account is created at supersite.com which tenant would they be allocated to?

          Show
          Ray Lawrence added a comment - A quick thought on self-registration, each tenant must have a distinct url (supersite.com/org-a ?) otherwise self-registration can't be a possibility. If the account is created at supersite.com which tenant would they be allocated to?
          Hide
          Wesley Janik added a comment - - edited

          Ray - yes, hierarchical management is exactly what I'm driving for. For clarity, I'd amendment your example as follows:

          Corporate

          • All employees
            • --+ Course 1
          • Org A
            • Org A employees
              • --+ Course 2
              • --+ Course 3
          • Org B
            • Org B employees
              • --+ Course 2
              • --+ Course 3

          The key here is corporate (e.g. corporate HR manager) can see the progress of all employees progress on courses 1, 2, and 3. The manager of Org A can see their employees and their progress on courses 2 & 3, but cannot see the employees (or their progress on courses 2 & 3) of Org B.

          Corporate would establish the content of courses 1, 2, and 3. An added bonus would be to allow the managers of Org A & B to establish courses for just their organizations, but I know that makes things messy regarding what the "corporate HR manager" has access to see with respect to those new courses.

          Show
          Wesley Janik added a comment - - edited Ray - yes, hierarchical management is exactly what I'm driving for. For clarity, I'd amendment your example as follows: Corporate All employees --+ Course 1 Org A Org A employees --+ Course 2 --+ Course 3 Org B Org B employees --+ Course 2 --+ Course 3 The key here is corporate (e.g. corporate HR manager) can see the progress of all employees progress on courses 1, 2, and 3. The manager of Org A can see their employees and their progress on courses 2 & 3, but cannot see the employees (or their progress on courses 2 & 3) of Org B. Corporate would establish the content of courses 1, 2, and 3. An added bonus would be to allow the managers of Org A & B to establish courses for just their organizations, but I know that makes things messy regarding what the "corporate HR manager" has access to see with respect to those new courses.
          Hide
          Ray Lawrence added a comment -

          Yup, I understand that.

          That approach is desirable for single and multi-tenant sites. IMO it should not impede the progress to a multi-tenant solution. But it probably needs consideration in with adding multi-tenant support as it's another route to enhancing user management there may be some dependencies.

          So is it time for an "Add support for hierarchical user management" issue linked to this?

          Show
          Ray Lawrence added a comment - Yup, I understand that. That approach is desirable for single and multi-tenant sites. IMO it should not impede the progress to a multi-tenant solution. But it probably needs consideration in with adding multi-tenant support as it's another route to enhancing user management there may be some dependencies. So is it time for an "Add support for hierarchical user management" issue linked to this?
          Hide
          Richard Sharples added a comment -

          Would be really useful once this feature is available.

          Show
          Richard Sharples added a comment - Would be really useful once this feature is available.
          Hide
          Martin Dougiamas added a comment -

          Hierarchical user management is a different issue, for sure. Glad to have that clarified. To whoever writes it, the spec needs to detail EXACTLY which points the visibility needs to be constrained and how.

          Note that ELIS is a solution for this already, too. http://remote-learner.net/elis_story

          Show
          Martin Dougiamas added a comment - Hierarchical user management is a different issue, for sure. Glad to have that clarified. To whoever writes it, the spec needs to detail EXACTLY which points the visibility needs to be constrained and how. Note that ELIS is a solution for this already, too. http://remote-learner.net/elis_story
          Hide
          Gareth J Barnard added a comment -

          On http://moodle.org/mod/forum/discuss.php?d=13211#p63585, Thomas van den Heuvel in his post of the 25 January 2012 describes a solution through using a switching configuration file which looks really elegant and possible to create a GUI for the management of.

          I think you could also use just one DB and have different values for:

          $CFG->prefix    = 'mdl_';
          
          Show
          Gareth J Barnard added a comment - On http://moodle.org/mod/forum/discuss.php?d=13211#p63585 , Thomas van den Heuvel in his post of the 25 January 2012 describes a solution through using a switching configuration file which looks really elegant and possible to create a GUI for the management of. I think you could also use just one DB and have different values for: $CFG->prefix = 'mdl_';
          Hide
          Juan Leyva added a comment -

          Congrats to Alex Büchner for the Multi-tenancy in Moodle paper.

          Just adding here the link as it's a good source of information about the different ways to implement something like Multi-tenancy nowadays

          http://www.synergy-learning.com/blog/synergy-news/multi-tenancy-in-moodle/

          Show
          Juan Leyva added a comment - Congrats to Alex Büchner for the Multi-tenancy in Moodle paper. Just adding here the link as it's a good source of information about the different ways to implement something like Multi-tenancy nowadays http://www.synergy-learning.com/blog/synergy-news/multi-tenancy-in-moodle/
          Hide
          Matteo Scaramuccia added a comment -

          Agreed: kudos to Alex Büchner!

          The only minor, for the nature of the paper, issue is the lacking of sanitizing input data in:

          <?php
          // Moodle configuration file 
          $moodle_host = $_SERVER['HTTP_HOST']; 
          require_once(‘/etc/local_moodle/’.$moodle_host.’_config.php’); 
          

          Using a switch statement:

          $moodle_host = $_SERVER['HTTP_HOST']; 
          switch ($moodle_host) {
              case 'domain1.example.net':
              case 'domain2.example.net':
          ...
                  require_once(‘/etc/local_moodle/’.$moodle_host.’_config.php’); 
                  break;
              default:
                  die('Nothing to See Here.');
          }
          ...
          

          could be a first way to avoid injections but it forces to add every single entry into the config.php missing the nice automation so mine is not a good suggestion.

          Show
          Matteo Scaramuccia added a comment - Agreed: kudos to Alex Büchner! The only minor, for the nature of the paper, issue is the lacking of sanitizing input data in: <?php // Moodle configuration file $moodle_host = $_SERVER['HTTP_HOST']; require_once(‘/etc/local_moodle/’.$moodle_host.’_config.php’); Using a switch statement: $moodle_host = $_SERVER['HTTP_HOST']; switch ($moodle_host) { case 'domain1.example.net': case 'domain2.example.net': ... require_once(‘/etc/local_moodle/’.$moodle_host.’_config.php’); break ; default : die('Nothing to See Here.'); } ... could be a first way to avoid injections but it forces to add every single entry into the config.php missing the nice automation so mine is not a good suggestion.
          Hide
          ahmad.k added a comment -

          Hi All,

          I wanna thank you for your efforts about this feature,
          And i am quite interested in having this feature in Moodle, cause we have something like Multi-schools environment.

          I wanna ask if there any plans for implementing this feature in Moodle 2.4 (or even 2.5), after dropping it from 2.3?

          Regards

          Show
          ahmad.k added a comment - Hi All, I wanna thank you for your efforts about this feature, And i am quite interested in having this feature in Moodle, cause we have something like Multi-schools environment. I wanna ask if there any plans for implementing this feature in Moodle 2.4 (or even 2.5), after dropping it from 2.3? Regards
          Hide
          Ali Hastie added a comment -

          Hi

          Wondering if there has been any progress concering the implmentation of multi-tenancy? Our College has merged with three other institutions and looking at the possibility of this feature for all our campuses.

          Cheers

          Show
          Ali Hastie added a comment - Hi Wondering if there has been any progress concering the implmentation of multi-tenancy? Our College has merged with three other institutions and looking at the possibility of this feature for all our campuses. Cheers
          Hide
          Evan Donovan added a comment -

          Is this still on the roadmap for a future release of Moodle in some form? Basically, my use case is that I would like to have one codebase and one set of courses, but multiple groups of users that can't see each other. There would be a user group administrator role that could create new users and remove users from the group, but wouldn't see any of the other users that were in other groups. Reporting would roll up to the user group level rather than all the way up, for the user groups.

          I was under the impression that ELIS provided this functionality, at least to some extent, but I haven't gotten it to work yet.

          Show
          Evan Donovan added a comment - Is this still on the roadmap for a future release of Moodle in some form? Basically, my use case is that I would like to have one codebase and one set of courses, but multiple groups of users that can't see each other. There would be a user group administrator role that could create new users and remove users from the group, but wouldn't see any of the other users that were in other groups. Reporting would roll up to the user group level rather than all the way up, for the user groups. I was under the impression that ELIS provided this functionality, at least to some extent, but I haven't gotten it to work yet.
          Hide
          Amir Elion added a comment -

          I think this plugin offers a multi tenancy solution of sorts:
          https://moodle.org/plugins/view.php?plugin=block_vmoodle

          Show
          Amir Elion added a comment - I think this plugin offers a multi tenancy solution of sorts: https://moodle.org/plugins/view.php?plugin=block_vmoodle
          Hide
          Michael de Raadt added a comment -

          Is this still a blocker? Are we still intending to actively pursue this?

          Show
          Michael de Raadt added a comment - Is this still a blocker? Are we still intending to actively pursue this?
          Hide
          Martin Dougiamas added a comment -

          Our approach at Moodle HQ will be to work on better administration of multiple installations, including copying of users and courses between them.

          Show
          Martin Dougiamas added a comment - Our approach at Moodle HQ will be to work on better administration of multiple installations, including copying of users and courses between them.
          Hide
          Luis de Vasconcelos added a comment -

          Each installation with its own codebase or with one shared codebase?

          Show
          Luis de Vasconcelos added a comment - Each installation with its own codebase or with one shared codebase?
          Hide
          Kevin Mueller added a comment -

          Each with its own codebase. Its a shame to see multy-tenancy effectively dropped from the roadmap. @Martin if a sponsor was found for this, would you reconsider or do you feel it just doesn't make sense to have a solution with a shared codebase?
          Best, K

          Show
          Kevin Mueller added a comment - Each with its own codebase. Its a shame to see multy-tenancy effectively dropped from the roadmap. @Martin if a sponsor was found for this, would you reconsider or do you feel it just doesn't make sense to have a solution with a shared codebase? Best, K
          Hide
          Ralf Hilgenstock added a comment -

          Hi Kevin,
          its not the problem to handle multiple Moodle systems with a shared code base. This is practice since several years. The main problem is that multi tenancy is not well defined. Each client has other ideas what multi tenancy means. We can identify more than half a dozen different concepts. Most clients excepct more a HR or training management system if they ask for such features. We decided to split the functionalities in seperate systems:

          • Moodle for online leraning offers
          • a seperate tool for course catalogue, booking and user related status report
          • a seperate tool as backend for course setup, bundling of courses, tenant administration, reports, notifications and approvals
            This gives us the option to add new types of trainings in a very flexible way.
            Ralf
          Show
          Ralf Hilgenstock added a comment - Hi Kevin, its not the problem to handle multiple Moodle systems with a shared code base. This is practice since several years. The main problem is that multi tenancy is not well defined. Each client has other ideas what multi tenancy means. We can identify more than half a dozen different concepts. Most clients excepct more a HR or training management system if they ask for such features. We decided to split the functionalities in seperate systems: Moodle for online leraning offers a seperate tool for course catalogue, booking and user related status report a seperate tool as backend for course setup, bundling of courses, tenant administration, reports, notifications and approvals This gives us the option to add new types of trainings in a very flexible way. Ralf
          Hide
          Martin Dougiamas added a comment -

          Yeah, as Ralf said, it's not about the codebase, you can easily run many Moodle sites from one codebase using config.php.

          It's more about the database. Making Moodle run multiple sites from one database (shared tables, but separated data) would take a long time to implement and will add a lot of complexity to Moodle itself, making it more fragile even for single-site usage. So it just doesn't make sense to do that.

          Show
          Martin Dougiamas added a comment - Yeah, as Ralf said, it's not about the codebase, you can easily run many Moodle sites from one codebase using config.php. It's more about the database. Making Moodle run multiple sites from one database (shared tables, but separated data) would take a long time to implement and will add a lot of complexity to Moodle itself, making it more fragile even for single-site usage. So it just doesn't make sense to do that.
          Hide
          Kevin Mueller added a comment -

          Thanks Ralf, thanks Martin,
          Yeah I also meant the database alongside codebase. Good to read your brief concept of how you handle it Ralf, appreciate it. I guess it is true that demands for multy-tenancy usually comes from the corporate sector. As for definition - I think Alex mapped that out nicely in his paper.

          Show
          Kevin Mueller added a comment - Thanks Ralf, thanks Martin, Yeah I also meant the database alongside codebase. Good to read your brief concept of how you handle it Ralf, appreciate it. I guess it is true that demands for multy-tenancy usually comes from the corporate sector. As for definition - I think Alex mapped that out nicely in his paper.
          Hide
          Gareth J Barnard added a comment - - edited

          +1 for Alex's paper, it is a fascinating read. I had thought that simply improving the config.php file with a variable populated by the sub-domain portion of the URL and then used in the database prefix and dataroot would work, but then reading Alex's paper demonstrated the other issues.

          So, perhaps there is the issue of performing a separation of splitting vanilla Moodle and add-ons in terms of what is available for each. Plus, what if each tenancy wants to operate different versions of Moodle or not upgrade at the same time?

          Is the solution more of a human one in terms of administration and a distributed computing one in terms of single sign on, users and cohorts? And if you want easy management and reporting then this would be a separate tool using web services for management and data extraction.

          Perhaps there is no one single solution, but rather a combination of separate improvements to allow greater distributed Moodle functionality.

          Show
          Gareth J Barnard added a comment - - edited +1 for Alex's paper, it is a fascinating read. I had thought that simply improving the config.php file with a variable populated by the sub-domain portion of the URL and then used in the database prefix and dataroot would work, but then reading Alex's paper demonstrated the other issues. So, perhaps there is the issue of performing a separation of splitting vanilla Moodle and add-ons in terms of what is available for each. Plus, what if each tenancy wants to operate different versions of Moodle or not upgrade at the same time? Is the solution more of a human one in terms of administration and a distributed computing one in terms of single sign on, users and cohorts? And if you want easy management and reporting then this would be a separate tool using web services for management and data extraction. Perhaps there is no one single solution, but rather a combination of separate improvements to allow greater distributed Moodle functionality.
          Hide
          Luis de Vasconcelos added a comment -

          FYI... Lots of people doing the same thing:

          Totara by paradisosolutions.com
          Elis by remote-learner.net
          Iomad by E-Learn Design (iomad.org)
          the VMoodle block (https://moodle.org/plugins/view.php?plugin=block_vmoodle)

          These have all implemented some form of the "multi-tenancy" concept.

          Show
          Luis de Vasconcelos added a comment - FYI... Lots of people doing the same thing: Totara by paradisosolutions.com Elis by remote-learner.net Iomad by E-Learn Design (iomad.org) the VMoodle block ( https://moodle.org/plugins/view.php?plugin=block_vmoodle ) These have all implemented some form of the "multi-tenancy" concept.