 Okay, let's kick this off. Just, can I just check that I sound clear? The audio's okay. You can see the presentation in front of you on the screen. Good. Oh wow, yep. Okay, so before we jump into that, let me just introduce myself. My name is Paul Holden. I work as a senior developer for Moodle as part of the Moodle Workplace team. So today I'm going to talk about one aspect of Workplace which has particular interest for developers and that is multi-tenancy. I will give a brief overview of what multi-tenancy is, how we use it and how you are likely to want to use it as a developer. I'll go over some of the resources that the Workplace team have created in order to assist you and hopefully give you a flavor by the end of it of what you can do with it. So before I get into anything overly technical, and for those who weren't joining from my colleagues' presentation about Workplace, I'm just going to go briefly over what multi-tenancy is. So multi-tenancy is a feature that allows an organization, a business, an institution to effectively run many instances of Workplace within a single site. Each instance is referred to as a tenant, so they are kept isolated from each other. The users of the site belong to a given tenant, and the users from one tenant are likely to experience a dramatically different look and feel of the site compared to users in other tenants. All the tenants have their own content, learning objects, activities, etc. And specifically in regard to Workplace features, they all have their own organization structure, programs, certifications, dynamic rules, custom reports and certificates. One thing that is worth mentioning is the final bullet point there, which is the ability to share entities between tenants. And this is something I'll touch on later, and it is of relevance to developers. Isolating tenant users, what does that mean? So as discussed on the last slide, multi-tenancy allows for multiple instances of Workplace on a site. One of the important aspects of this is the concepts of users belonging to a tenant. From a manager or administrative perspective, the users within each tenant are isolated from users in other tenants. For example, if I am a manager and I want to allocate a user to a program or issue a certificate or want a badge, I can only do so. So those users within my own tenant. So the bullet point there about the roles that Multi-Workplace creates for you, these are predefined and allow you as an administrator to delegate responsibility within the tenant to users. So you can have a tenant administrator and manager and a user. And the documentation I've linked here at the bottom is a good place for you to read about those things. Now let's get to the part when we talk about how user-plugging developer needs to work with this. So these are the three really key points that need to be covered by a developer working on a Moodle plugin with the intention of also supporting Workplace. I'll cover each of these three points in more depth shortly. Briefly, we want to make sure that any given user can only view other users they share a tenant with. So this is the first two bullet points on the slide. And for those courses that are shared between tenants ensure you are following existing Moodle guidelines regarding group mode settings and how they affect list of users. Let's look in detail about each of these things. User listings. So assuming that you are familiar with Moodle, you will have seen user listings everywhere. And they are used throughout Moodle on various UI and various screens. So now we will take the assumption that you have a plugin or a piece of code that provides interactions for users or reports users interactions within your plugin. So this part is especially relevant to you. The distinction on the slide between the first two points is useful for you to know. And that's the distinction between accessing or listing users outside a course versus inside a course. If you are listing users inside a course, you should already be covered assuming you are respecting the course group mode settings. So this is a part of core Moodle and is no different in Workplace. Assuming you are respecting the course group mode settings, you will already be covered. There are however some plugin types that may exist inside a course that report on non-enrolled users. So these may be enrollment plugins or any kind of report really. These plugins must take note. To implement the safe listing of users, we have a component callbacks. The component callbacks are a common feature of Moodle. They allow any piece of code to call methods from installed plugins. So we have a component callback called get users subquery. This exists in the multi-tenancy plugin. And it performs all calculations regarding the current users' tenants and capabilities and generates a little piece of SQL that you can insert into your query that will effectively make it tenant aware. So current user capabilities that are taken into account for this. So one of the capabilities that is granted to a site administrator by default is the capabilities switch between tenants, which allows any user with this capability to view users from any tenant. And this is automatically taken into account for you in the component callback. I'm just checking the chat. I think I'll continue. So individual users, this is to ensure that any given user of the system is able to access the details of any other given user of the system. So in addition to the normal capability checks that your plugin may implement, you also need to ensure that they all respect the multi-tenancy rules. In order to achieve this, we have another component callback in the multi-tenancy plugin, which is listed there in the second bullet point. Similar to the one I described on the previous page, this method performs calculations based on the current user's tenants, whether they can view a given user based on belonging to a shared tenant or they're having the capability to view users in all tenants. So this is related to the previous slide where your plugin, your code, your piece of work has a listing or a report of users and you want to drill down to more in-depth detail by clicking on an individual user. By using this callback, we can ensure that the user is able to access these details. So the callbacks, everything I'm talking about now is all referenced in the links which we will share at the end of the presentation. They're also part of the presentation as well as I go through. So I've talked a couple of times about respecting the course group mode within a course. So this isn't something new to Workplace, this is just something that exists within Moodle. It is a way of isolating groups of users within courses. So the way tenants work is about isolating groups of users within tenants but with shared entities, i.e. entities that users from multiple tenants can access, we need to preserve that isolation between the users in each tenant. So this is achieved using Moodle groups within the course. So the recommendation would be then to set the course up when designing it in separate group modes and preferably forcing that group mode. So as a developer, all you need to do is fully support these course group mode settings. And there's a documentation here I've added at the bottom covers that in depth. All these documentation for developers is really in depth and definitely work looking through. So I've given you a talk about what the three really key things are. Let's now talk about some of the resources that we have that can help you achieve this. So if any of you access this Moodle Workplace site on GitHub, this is public. We publish code, examples, repositories in here. I'm going to talk about some of the key ones which I think will be more useful for you. So we have the multi-tenancy testing platform. We have an example plugin that uses this multi-tenancy. We have some integration tools and the final point is perhaps less relevant to developers but it's very relevant for translators among you. We publish information which aids the translation of Workplace. So the multi-tenancy testing demo, what is that? So Workplace itself is composed of really three things. So we take the car Moodle which is something you would all be presumably familiar with. So currently that is version 3.8. We, as a matter of course, tend to track the latest stable version. So in addition to Moodle, there are a selection of car modifications to support multi-tenancy. And we have a stripped down version of the multi-tenancy plugin. So this plugin is similar to the plugin that ships with Workplace and comes with a lot of testing utilities which is obviously important if you write in code for that. And the important thing to note, it does include an identical public API to the version in Workplace. So if you are writing code against the API provided by this plugin, it will work in Workplace. If I just briefly skip back to the car modifications which I rather glossed over. So when I talk about the car modifications, to support multi-tenancy across car Moodle, there are various places which we have had to modify. So this is places where you would select from users. So by default Moodle would give you a list of all users across the site whereas in Workplace we really only want them to give you access to users within your own tenant. So the testing demo, it doesn't include all the modifications to support multi-tenancy but we have included enough to give hopefully quite comprehensive examples of how these changes would work in practice. So we have included modifications for the user selector element. So this is a common element used across Moodle for selecting users. The manual enrollment plugin and the awarding and viewing of user badges. The commits are all logically grouped within the repository and are worth just looking for interest and if you want inspiration about how your code should look. The example local plugin repository. So this is fairly straightforward. It has basic functionality but the important thing it does demonstrate is that it is possible for a single code base to support both car Moodle and Workplace multi-tenancy at the same time. Having the support for both products in a single code base is obviously a benefit to anyone who wants to support both products because you don't have to maintain separate code bases for each. This is a great example to look at. It includes PHP unit and BHAT tests with Travis configuration for testing on both Workplace and car Moodle. So this is something we think is very helpful but we would also love to see fellow developers diving into this and experimenting, playing with it, getting involved. Feedback on this is always welcomed. Integration tools. So your integration tools. These are your tools for rudimentary error checking, unit testing, ensuring that your code conforms to a baseline set of coding standards. So the coding standards are all well documented for Moodle developers. Some of you may be familiar with the Moodle plugin CI suite. This is very popular for community developers, especially with its tight integration when used with Travis. So for those who are familiar with it, that's great for those who aren't. I mean, whether you want to work on Workplace or Moodle, I think it's a great tool for you to have in your armoring, definitely worth checking out. So we use the Moodle plugin CI suite internally within the Workplace team. We have continued developing these tools and some of our changes have been submitted upstream to the community addition for the benefit, for the wider benefit of the community. So in this repository you will find all of the additional checks and changes we have implemented. All worthwhile for you to know about. So again, feel free to explore these changes. This suite can be used as a drop-in replacement for the community addition or just as a means to introduce automated code testing for those who aren't currently doing that. Let's continue. So the language files, I'll cover this because it's a public repository. And just so you're aware of what it is, it's basically the language packs for the entire Workplace system. So that's all of the plugins provided within a Workplace setup. All the language files are provided in this repository. It's versions, so a translator is able to view this repository and track the changes between versions, get context for where the language strings are used. And basically it's a tool to aid in translation. I mean obviously we won't work place to be translated to as many languages as possible and if this tool helps to achieve that, then we're all for it. API usage. So the recommendations on this slide are really not controversial. They're no different from interacting with any APIs from any system, Moodle or otherwise. The recommendation is use the APIs basically. The callbacks that I've mentioned should always be used. This way you are ensuring it works and I know as a developer there's always a temptation to bypass that, explore the back end yourself and manually generate the queries. Of course you can do that. I would recommend you don't do that and always stick to the API, the public API that is provided by the multi-tenancy plugins. The key reason is that your plugin will continue to work while we continue developing a workplace. So while we refactor the back end, we implement new functionality. The intention is always to provide backwards compatibility and ensure we don't break third party code really. Before we move to any questions or before I sign off and let you all get on with your day, I'm just going to talk about what's coming up in upcoming versions of Moodle, of workplace or specifically in regard to the multi-tenancy. So this was briefly touched upon by Emilio in his overview of workplace. So it's really the concept of tenant shared learning and improving what entities can be shared between tenants. So if you see the list, you're looking at the common workplace components, you've got program certifications, etc. And it's about improving how those resources and entities are shared between tenants. Let me see. I'm just checking the chat. I don't think there's any questions yet. So I hope that was interesting. Getting community developers, plugin authors involved is something that we want to encourage. Obviously we want to increase that ecosystem of third party plugins that are available for workplace. I believe this presentation will be shared afterwards. All the things I've talked about mentioned are links. The documentation is thorough in places. It's a wiki. We'd always appreciate your feedback and help with improving it where you see fit. All worth exploring. So here is the link to the workplace homepage that will give you more background or context about workplace as a product. It will provide information about talking to partners if you are interested. There is my email address. Feel free to reach out to me or any of my colleagues on the team. I believe there's also a forum on the MOOC website so I'll be around to answer any questions after this. So I'll just thank you for watching and hopefully next time I'll see you physically at a MOOC. So that's me. If anybody does have any immediate questions now, I'm glad that someone is going to go and check those repositories out or just feel free to reach out whenever you like. I've got some private messages as well. I'll try and get to those. Yes, APIs are obvious. A great thing to use. And good, you're already checking out the workplace repository on GitHub. Can we create multiple instances of database for Moodle? I'm not sure exactly what you're asking there. The intention of multi-tenancies is that you have a single site and all using the same database depending on how exactly you're setting up your systems rather than having a multiple database for each tenant. Are you able to share courses among the tenants? Yes, Sandy. That is something that is currently implemented and used and is something as a developer that is useful for you to know and know how to work with. Out of interest, do we have many developers or people here who are interested in making their code work with Workplace? Sandy asked the question, for shared courses, should we use group mode for this? Yes, for shared courses in order to maintain isolation of the tenants, what Workplace will do is create a separate group within the course for the users of each tenant. So this is something to be aware of for curriculum designers when they are creating the course that for all shared courses they must use separate group mode. Front page settings. Sandy, are you asking about whether the front page looks different for each tenant? Summit, I will get to your question shortly. Sandy. So currently the front page, either page that lands after the user login, that is currently set. There is some requests which I think are quite similar to what you are asking about having tenant-specific front pages. So to answer your, what I think is your question, each tenant has the same front page after logging in, but there is some work on the roadmap to look at that. The login page is one of the things that can be customized per tenant and that comes down to the look and feel of the site and that can be completely different for each tenant. But once they have logged in, other than the styles, the dashboard has a familiar look across all the tenants. Anjali, where can I get a step by step manual to set up this for my organization? I recommend you reach out to your local Moodle partner. They will be able to provide a lot more information about how you would get started with this. Summit, let me get back to your question. Apologies for the delay. Is group mode within-course per department division-wise? The groups that are created within a course are named after the tenant that the user belongs to. Your second part is about reporting. Department level reporting is, yes, reports can be created to drill down by department level, which I think is what you're asking. Please clarify if I've misunderstood you. If Fiona recommends if you have any general questions about workplace, you can ask them here and I will try to answer them the best I can. Kudai, you're welcome. I hope it was useful. I hope there is something that you can take away from this. Suje, every company is isolated. Is that the case? There will be any relationship between child company and parent? So it depends if you're talking there about tenants or about organization structure. So with tenants, there is no current hierarchy where a tenant belongs to another tenant. A tenant is considered isolated, but within your organization structure, it is possible to create the relationship you describe there between a parent company and franchisees, for instance. Yes, so that is possible. You're welcome. Like I say, if there are any future questions anyone has, you've got my email address there, there's the forums, there's multiple mediums, which can be used to contact me or my colleagues, and we're always happy to help.