text:
Type: New Feature
Status: Closed
Priority: Blocker
Resolution: Won't Fix
Affects Version/s: 2.1
Fix Version/s: DEV backlog
Component/s: Administration
Affected Branches:MOODLE_21_STABLE
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.
Gliffy Diagrams
Issue Links
- blocks
MDL-23534 Suggestion to use Front Page short name instead of the language string
- Closed
- has a non-specific relationship to
MDL-46401 Use cohorts to restrict display of course categories and set themes
- Open
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
Petr has been developing a spec that introduces a new "Tenant" concept and a new level of contexts.
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));
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.
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.
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.
"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.?
"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.
"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.
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.
" 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.
Blogs: add tenantid to blocks - tricky to separate these, it could probably work with different tenant domains only, better than disable.
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.
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!
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.
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.
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.
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.
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)
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.
"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.
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.
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.
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.
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.
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
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.
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.
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?
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.
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.
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.
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.
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!
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.
So you cant assure that this will be part of 2.2 release in December.
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.
+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.
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,
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?
I was looking the code Petr is developing at:
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?
Petr has also proposed some milestones and a timeline for completing this development:
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?
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.
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.
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).
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
Agree with Juan and Ray this feature would be incredibly valuable.
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
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?
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:
- Upgrades
- Settings (presets shared across all sites)
- Centralised reporting
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.
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.
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.
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?
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
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.
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
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.
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.
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?
"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.
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.
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?
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!
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.
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.
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!
To Dan:
One training provider
20 clients as described above.
20 moodle installs, 20 databases, 20 moodledatas + 1 global admin app
1 moodle install, 1 database, 1 moodledata
Here's a diagram: not sure which stage we're at currently.
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.
One training provider
20 clients as described above.
20 moodle installs, 20 databases, 20 moodledatas + 1 global admin app
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
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
Juan, this themes issue is one that will have to be addressed. Tenant specific branding of their respective spaces is crucial.
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.
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)
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.
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.
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?
It seems it was deleted in the 2.3 Roadmap http://docs.moodle.org/dev/Roadmap
I believe that this project has been cancelled ("postponed indefinitely") by HQ due to its complexity. Is this correct?
I believe that this project has been cancelled ("postponed indefinitely") by HQ due to its complexity. Is this correct?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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?
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.
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....
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.
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.
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?
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.
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?
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.
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.
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.
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?
Ray - yes, hierarchical management is exactly what I'm driving for. For clarity, I'd amendment your example as follows:
- All employees
- --+ Course 1
- Org A
- Org A employees
- --+ Course 2
- --+ Course 3
- Org A employees
- Org B
- Org B employees
- --+ Course 2
- --+ Course 3
- Org B employees
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.
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?
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
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_';
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
Agreed: kudos to Alex Büchner!
The only minor, for the nature of the paper, issue is the lacking of sanitizing input data in:
// Moodle configuration file
$moodle_host = $_SERVER['HTTP_HOST'];
Using a switch statement:
$moodle_host = $_SERVER['HTTP_HOST'];
switch ($moodle_host) {
case 'domain1.example.net':
case 'domain2.example.net':
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.
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?
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.
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.
I think this plugin offers a multi tenancy solution of sorts:
Is this still a blocker? Are we still intending to actively pursue this?
Our approach at Moodle HQ will be to work on better administration of multiple installations, including copying of users and courses between them.
Each installation with its own codebase or with one shared codebase?
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
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.
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.
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.
+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.
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.
Closing this because it's simply not going anywhere with core Moodle.
This related idea was proposed: MDL-46401 ... it's a greatly simplified idea that just adds category and theme settings to cohorts (and should probably stay simple like that) but if you think it would be useful to you anyway please vote for it.
Hi I an new in moodle. anybody help me how to create multi company in moodle.
Please come over to the help forums of https://moodle.org/ Sandeep and ask your question there There are some possible solutions.


text:
It looks like you're new here. If you want to get involved, click one of these buttons!
See, this is why I love this site. I can just see Suzie, Mike, Bill and Garrett sitting around saying "There haven't been enough tears in the forums lately, lets write an article to incite the masses. Something positive about a popular (everywhere but here) game should do it.".
Hooked every one of them.
I want a mmorpg where people have gone through misery, have gone through school stuff and actually have had sex even. -sagil
Originally posted by Zekiah
Originally posted by Kaynos1972
Tomorrow on MMORPG, after the 5 things they did right, the 25 they did wrong.
Yeah, that's gonna happen lol.
It is interesting what's missing though. How about gameplay? Items? Immersion? Depth? Crafting systems? Classes? Skills?
Lol. You guys can and should do better than this, really.
Where's the balance? Where's the other side of the story? Where's the other information for your viewers?
I suppose that's about as likely as your quote.
Zekiah sums it up nicely.
I logged on to D3 last night for the first time in a week to check if i had sold the last of my hardcore items, looking at my friends list there was 1 person playing, lots of friends had not logged on for days some even weeks. So please don't tell me that Blizzard did things right, gamers that have played good games before are just not playing this pos called d3.
Originally posted by Z3R01
THe AH takes away from the game. Having the ability to look for level appropriate items with the exact stats you want make damn near every drop you find worthless. Sure you can ignore the AH but its really hard when its so easy to spen 100k gold and completely twink a leveling character. I honestly would rather trading go back to shady sites and Ebay... It could easily be ignored.
You know that button on the character select screen labled "Auction House"...don't click it. Problem solved.
I do agree that buying items on the AH defeats the purpose of the game. Getting that upgrade drop is what makes these games fun. If it was just a matter of beating the boss...we'd all be done after completing normal mode.
"I've been able to gear up some of my characters for no more than the gold I find lying about in game."
Don't you think however that the gameplay would be so much more satisfying and rewarding if you were able to adequately gear up your character with gear you found?
After playing through to 60, I started a new character I found I was getting a lot more excitement from the possibility that gear I found might be better than what I was wearing, which is a fair possibility in the beginning of the game. Later on however as most of the gear is 10 levels below you it becomes much less of a possibility. I don't mind the idea of the AH, but I sure wish they hadn't geared the drop tables to make the AH a better option for gearing up than just getting drops.
I disagree on all fronts with the article. I am not sure what Blizzard was aiming for with D3 other than making a fortune of course.
The story was quite dull, dragging out former enemies for no apparent reason. In fact it almost felt like a redo of D1 rather than a new tale in the same story line. THe irony is that the video that Blizzard did (which I quite liked) set this up more of a corruption of Heaven by the Angels themselves, which would have been a fantastic story.
There was no need for Leah, no need for her mom, etc.
You could have just set up the story as Diablo returning in the form of a corrupted angel thrown out of heaven and made the fallen one the one in the video ( i just forget his name at the moment) rather than Tyrael.
On the game dynamics itself, I loved the graphics and effects etc but do not understand for the life of me how they made the decsions on the classes. What was wrong with the existing classes from D2? Paladin and Necromancer would have fit right in. So would Amazon. The Wizard incarnation from D2 would have been fine here as well. Mind you, I enjoy playing the game, but I am so utterly confused why they went in this direction.
Oh well. Waiting for Borderlands 2.
Story...? There was a story...? O_o
You sir, need to go play some real RPGs that actually have a good storyline sometime...
Can't help to think that someone got paid by Blizzard to post something like this...
I complete disagree with everything on the list. There are stuff I believe was done right but yeah...
Really... the story was good? I really need to go write a novel cause if you think the story in this game is good I would completely blow you always writing a book about a random story I just made up in the back fo my head.
The only good part about the story is the content they took from other sources and involved in the game. Its the only reason anything at all sounds good. The story outside taking material from the novels and all is just one of the WORST stories around. That being said, its lucky in this game I dont' judge it by story or it would be one of the worst games I played.
End of Act III and the beginning cutscene of Act IV still has my mouth dropping. I could watch that over and over again.
I have enough millage in D3 to feel ok with not liking it. I wouldn't recommend anyone to go beyond the initial difficulty level. Repetition is the outcome of lack of content. And grinding is not fun.
i actually disagree with every point in this article.......i don think that has ever happened.
D3 got very little right. Luckily they got the most important thing right which is combat.
Playing: PO, EVE
Waiting for: WoD
Favourite MMOs: VG, EVE, FE and DDO
Any person who expresses rage and loathing for an MMO is preposterous. He or she is like a person who has put on full armor and attacked a hot fudge sundae.
Im sorry but i cant agree with any of them, so lets see as the OP said:
5 - Auction House: Argue that is easy to toon up characters. Thats the point of an ARPG getting better gear to progress ingame, if you can buy your items from the AH theres no point in playing the game.
4 - Whimsyshire : Yes this is the endgame, Little poney and rainbows, i know theres a cow level in D2 but hey! THERE IS NO COW LEVEL!
3 - Companions: So you dont feel alone, a helpfull companion will follow you and get one shot everytime.
2 - Story: The best of the Three, there is girl that doenst believe in monters but she spend half the game killing them. Whats the story again!? i only finished the game 5 times.
1- Adrian, Cain, Leah: Who?
So many things that bliizard did right and none is the only thing blizzard can do in my opinion:
The Artwork in general, diablo 3 have many haters but everyone of them can agree that the artwork, music and cinematics are the best thing they can offer, besides that theres nothing else.
Watch this from 4 yrs ago and feel even more ripped off, yes this is the game four years ago, how can that be better then today, thats my question:
Beta tester maniac
Disagree with the story. Sorry. People might look at me funny but I ended up reading the sin war trilogy while waiting for D3. The story was a huge let down for me. Lots of things unanswered from the books and such.The story really pissed me off. If the writer of this article meant the cutscenes by story then I agree. But IMO no.
5 out of 100. Diablo III is far away from diablo 2 in gameplay. Now its platform for chinese farmers to feed their families.
No fate but what we make, so make me a ham sandwich please.
Well glad you like the game, Suzie, but I personally have to disagree with you on every point, as every one of them are things that make me dislike this game. I'm not going to get into a point by point list as it is all down to one's opinion and personal taste.
I will say however that to me Diablo 3 very much resembles the difference between cool Elvis and Vegas Elvis. To me D3 is very much an aging bloated has-been wrapped up in glitter and nostalgia, whos main drive is not to perform or create, but a vain drive to retain its relevency and to fleece its fans out of a bit more of their money. Which does not mean it isn't still enteraining, but much of its original magic has faded away leaving its current state more pathetic than invigorating.
"Gypsies, tramps, and thieves, we were called by the Admin of the site . . . "
The only thing they did was make sure they could make money off us and the gold farmers.The company sucks now.Hell might as well call blizzard a chinese company.You want to play diablo 3 then go play torchlight 2. Dont give in to these money grubbing punks any more.
The problem with d3 was hugely part and partial to the ah. In a game so centered around loot that the loot itself is the endgame the AH becomes the endgame. This is a paradigm I absoloutely cannot agree with. Sure you could "Play" the endgame by snagging bargain purchases on the ah and turning them around for profit. There are people so bent on this "endgame" that they play the AH game more than they play the game. So keeping it simple ah with zero actual endgame is perhaps the worst thing they could have done.
The idea of whimsey was great but they deemed that they want you to play the game how they want you to. Whimsey was consequently nerfed to oblivion and back. The only redeaming feature is 4-5 rares in a zone. A concept on equal par as cow level ruined by suits.
Companions are perhaps the one and ONLY part of this post I will agree with. This being the only true innovation to the trequal. Sadly its not entirely innovatiive but ill take what I can get.
Story.... A bit short a bit too similar to d2 in several ways. Overall not entirely impressed give that they had 10 years and this was the best they could come up with. Highly unimpressed at the lack of imagination. I would rip the story a bit more but wont spoil it for those reading that are looking to play in the future.
Adaria, Cain and Leah. These characterrs fall into part of the story and should be classified as such. Deckard cain was an old man in diablo 2. The story line takes place 20 years after diablo2. This man should be dust by now. Leah... an unimaginative MacGuffin The writing on the wall as to her was well plastered in act 1. In 10 years they really could not come up with better plot devices? Could they not have been so quick to spill the beans so early on. Adria was simply the antagonist working to achieve her goals. It would have been nice if they could have added some backstory rather than 1 or two lines of dialogue.
Unimaginative, flat, and short lived unless major overhauls are made I give this game 4/10 on its creativity, playability and replayability.
" With Whimsyshire, a Mario-esque looking zone packed"
Obviously the writer has never played Warcraft 3.
Yet another D3 article.
But here someone is trying a bir too hard to promote this game on MMORPG.com. Taking even generally accepted bads of a game and glorify them as positive points...getting a bid obvious we sold out to Blizzard here aint we?
Taking 5 mediocore, subpar and bad points and claim them 5 positives? Game doesnt seem to offer much eh?
There is just a ton of things wrong with this post. I can't go into it all however i have to say that this post is like one of those media tabloid channels on tv that are paid to put a spin on something that anyone can see is completely the opposite of what's being claimed. It's reminiscent of another article we've all seen of the launch of SWTOR.
Simply put, I disagree with everything that the OP stated. Amazingly, everything. For the record, every site that has a stream of people discussing D3 is probably 90% anti-D3. Saying just these forums is foolish. The game offers smooth combat, OK story, interesting characters (not the ones you mentioned...Imperius being one), and the best thing by far is the nostalgia you try to feel while playing.
WTF MMORPG?! Really? If I had to name the five things that Blizzard fucked up the most on, these "Five things Blizzard got right" would be the list. Seriously.
Error: 37. Signature not found. Please connect to my server for signature access.
Unfortunately an unbiased review is impossible for a site like MMORPG.COM now. If they were to write an honest review and slate Blizzard for what is basically a huge internet scam they'd never get invited to another Blizzard press conference, or to betas of future games like Titan.
Journalistic integrity has been sacrificed for future participation in Corporate Spin.

subset: commoncrawl


text:
|Print Page
Camping on Public Lands
The public lands are open to camping. There is no fee for dispersed, primitive camping, but there is a limit to the number of days one may camp in the same location. Dispersed, primitive camping is camping where there are no developed amenities such as water or toilets. Primitive campers are asked to follow the "Leave No Trace" land use ethics. Dispersed camping in a motorhome is allowed, but dumping black or gray water on the public lands isn't allowed. Please empty waste tanks at approved locations.
Leave No Trace: http://lnt.org/programs/principles.php
The BLM Nevada occupancy rule
A person may not occupy undeveloped public lands or designated sites or areas for more than 14 days within a 28 consecutive day period. Following the 14 days, a person and their personal property must relocate to a site outside of at least a 25 mile radius from the occupied site for a period of 14 days.
An occupancy limitation rule was established to reduce user conflicts caused by long-term occupancy that may hamper reasonable opportunities for other members of the public to camp in or use the same area. Additionally, long-term occupancy can result in vegetation trampling, erosion, wildlife disruption and improper waste disposal. BLM established occupancy limits for camping with the publication of a notice in the Federal Register on Oct. 5, 1993.
BLM Nevada Campgrounds
Battle Mountain District
Carson City District
Elko District
Ely District
Southern Nevada District
Winnemucca District
For information on other improved, fee campgrounds in Nevada:
Nevada State Parks: http://parks.nv.gov/
U.S. Forest Service (Humboldt-Toiyabe): www.fs.usda.gov/htnf
|Last updated: 04-02-2014
|USA.GOV | No Fear Act | DOI | Disclaimer | About BLM | Notices | Social Media Policy
|Privacy Policy | FOIA | Kids Policy | Contact Us | Accessibility | Site Map | Home


text: Wen_Jiabao_09.JPG Business, Finance & Economics Did JPMorgan buy influence in China? The Takeaway November 15, 2013 JPMorgan Chase wanted a bigger piece of the Chinese financial market. Now, the US government is investigating what the bank was willing to do to get it. The latest revelation is that the bank hired the daughter of former Chinese leader Wen Jiabao as a consultant.


text:
|NOTE: This product is no longer being sold and might not be supported. View the End-of-Life Notice to learn:
The Cisco 1538 series Micro Hub 10/100 provide flexible 10/100 autosensing Fast Ethernet desktop connectivity for creating high-performance, manageable LANs at an affordable price. The eight-port 10BaseT/100BaseTX autosensing hubs provide 100Mbps peak aggregate throughput, up to ten times the performance of traditional Ethernet hubs. Ideal for enterprise remote branch offices and small and growing businesses where management is a requirement, the Cisco 1538 series Micro Hub 10/100 deliver the most cost-effective and powerful management option in their class.
The Cisco 1538 series is a member of the Cisco Networked Office stack family of stackable desktop products designed to provide complete networking solutions for small businesses and small branch offices.
End-of-Sale Models
Data Sheets and Literature
Data Sheets and Literature


text:
Substitute 3 1/2 cups miniature marshmallows for the large marshmallows.
Instead of making indentations and adding peanut butter cup candies, press 1/2 cup of candy-coated peanut butter candies into the cereal mixture.
These make great on-the-go snacks. Just place in a plastic container, and they're ready for the park or beach.


text:
Cougar Prato Flat
Sorry, this item is sold out!
Looks like you've got more shoe shopping to do - have fun!
Looks like you've got more shoe shopping to do - have fun!
Item # 274469
Stay cute and comfy in the Cougar Prato. This adorable patent slip-on is perfect for any season and any day of the week!
- Crinkle patent leather upper with contrast stitching
- Cushioned insole
- ¾" molded heel
- Flexible synthetic sole
- Imported
By: ABTee
Location: Maryland
May 02, 2013
Comfy Slip-Ons
"I used these shoes for a walking tour and they were great! I wore no show socks with them which were necessary because the black on the inside of the shoes may stain your feet if barefoot. Very comfortable and the patent is versatile--you can wear them to dress up an outfit or dressed down"
By: lap2
Location: Union,NJ
March 19, 2013
"very comfortable and they style. i am on my feet all day and have to wear up to date shoes, and these are it."
Click anywhere to close this.


text:
Community Information Database
You are browsing the Subject Heading Outpatient Drug Detoxification which contains 3 record(s)
Page 1 of 1
- Camp Recovery Center
Service hours: 24 hours a day/seven days a week. The Camp Recovery Center provides highly structured, nationally accredited drug rehab programs at every phase of the recovery process. ELIGIBILI... [Full Record] [Add to Personal List]
- Janus of Santa Cruz
Janus DUI Programs: 831-462-5267 direct Janus Community Clinic: 1000A Emeline Ave. Santa Cruz, CA 95060 831-425-0112 831-425-1847 fax Janus South County: 284 Pennsylvania Dr., Suite 1 Wat... [Full Record] [Add to Personal List]
- Recoverywave.com
Listed on the website are four basic approaches to the treatment of addiction, with options listed to the left. 12-Step (12 step) Programs These programs assist users with a step-by-step path to ... [Full Record] [Add to Personal List]
Page 1 of 1


text:
Here's a visualization concept I came up with a while back to look at the way search engines and word-of-mouth affects hit frequency on the iBiblio web-traffic log. iBiblio consists of around 420 sites. Each one of the circles you see represents one of the websites. The size of each pie slice inside grows with respect to the number of hits by individual search engines (see the legend for which ones). The size of the circle grows with respect to the overall number of hits by people other than search engines. Hits are counted by number of unique incoming IP addresses per day. Links get drawn between cliques of websites where more than 1/4th of the unique IP addresses are the same on that day, meaning, more or less, that those sites often share traffic.
This viz was developed entirely using Haskell and Cairo to crunch the weblogs and draw the data. The total amount of data was around 10TB (yes, terabytes), and the visualization took about a day to process into a static animation. Note that these are both size-compressed. The original is meant to run on a wall-sized (16′x9′) or on our specialized visualization dome. If you click on the image, you can see the original size.
A month in the life of iBiblio


text:
Tales of the Unexpected
Aspects of contemporary Australian art
Introduction | Foreword | Essay | Works | Gallery
Rosemary Laing | Anne Wallace | Lyndell Brown and Charles Green | Kate Beynon | Sally Smart | Robert Boynes
To dream one's life in order to live it . . . Lao Tzu
Tales of the Unexpected: aspects of contemporary Australian art is about the power of the human imagination to dream new worlds into being. It is about engaging with experiences of the real world and transforming them to create poetic, 'fictional documentaries'. It is about transcending linear time and acknowledging the simultaneity of multiple existences. It is about blurring the boundaries between fact and fiction to illuminate states of being.
Included in the exhibition are some of this country's most thought-provoking and engaging artists: Kate Beynon, Robert Boynes, Lyndell Brown, Charles Green, Rosemary Laing, Sally Smart and Anne Wallace. Working in quite distinctive ways across a range of media – painting, photography, collage, wall installations and video animation – all the artists invoke performative, theatrical or filmic possibilities in their work, suggesting open-ended tales and dream spaces. Through the inventiveness of their ideas and the unexpected juxtapositions of images and locations, they invite the viewer on journeys of mind and imagination.
Within the flexible framework of 'fictional documentaries', the aim of the exhibition is to highlight several remarkable series or groupings of works – to reveal the development of particular ideas through the 1990s and crossing the bridge into a new century. Rather than attempting a wide-ranging survey, the number of artists is deliberately limited to allow for a depth of representation. In some instances the selection takes into account earlier contextual works, while in others the focus is on the intensity of investigation around a specific theme.
The exhibition also takes into account the fluid boundaries between various media in the artists' works – particularly in relation to painting and photography or cinematic associations. For some of the artists this is revealed through visual and conceptual analogies, while for others it is about direct physical interventions in the process. It is possible, for example, to encounter the ways in which a painting can incorporate still photography and/or recall aspects of film; a photograph can encompass painting or performance, a digital print can be based on drawing for animation, and collage (usually associated with small scale work) can mutate into an evocative, dramatic wall installation.
Interestingly, in a world dominated by technologies, these artists often provide unexpected, distinctly 'low-tech' innovations. Many people have, for instance, been deeply surprised that Rosemary Laing's photographs in her flight research series are not digitally manipulated but instead involved a stunt-performer to enact the dramatic images of the body liberated in space. Also surprising are the photographic Duraclears of Lyndell Brown and Charles Green – large luminous transparencies of their meticulous composite paintings incorporating streams or analogies and art historical references. Kate Beynon, on the other hand, uses video animation in her cross-cultural dialogues as an extension of her drawing, striving to keep a two-dimensional quality in the work (as if the drawings themselves have come to life).
The filmic look of Robert Boynes's luminous paintings (which include screen-printed photographic images) is informed by intensive reworkings of the painterly surfaces to convey the movement of people through city spaces – as if they are walking or drifting ghost-like through the frame. In contrast, Anne Wallace's haunting, theatrical images appear to be forever held in time – the cinematic quality of her paintings relating more to a particular 'look', drawing upon a 1950s Hollywood aesthetic to engage with subconscious and psychological realms of human inquiry.
A sense of theatre recalling dream-like fairytale silhouettes and shadow worlds of Goya's famous etching The sleep of reason produces monsters appear in Sally Smart's fluid, filmic, unfolding imagery in her Family Tree House installation created specifically for Tales of the Unexpected at the National Gallery of Australia. Here, images of the body, furniture, architecture and natural phenomena, overlap and interweave to spin evocative and fantastic tales.
The diverse artists in Tales of the Unexpected: aspects of contemporary Australian art provide the viewer with much to contemplate. They do not convey narratives with neat beginnings or endings. Rather they suggest something altogether more expansive in the form of fragmentary open-ended tales and dream-like poetic spaces that are part of the endlessly perplexing, entrancing continuum of imaginative and unexpected possibilities that the world has to offer.
Deborah Hart
Senior Curator
Australian Painting and Sculpture