In the last few episodes we learned how to install the Platform and then develop and unroll our original application. Another very common scenario is deploying somebody else’s application. Like this 1C:Drive solution developed by 1C company. This is what today’s episode is all about.
So, this is a distribution package I’ve received from developers. I’m unzipping it. Running the setup executable. Next. This is a folder the Platform suggests we install a package to. Let’s copy this path, accept the suggestion, and this is it. Let’s see what we’ve got installed. So, this is the package content, and here is the CF file containing the application and the DT file with the same application and a demo data set.
So, now I can create a new infobase and restore either of these files manually. Or, I can select either of them right here, and the Platform will do the rest, just like this. OK. Let’s open the infobase with the Designer and start setting the application up. The first thing we need to do is to set up users and their access rights. So, let’s start with Roles.
Let me show where the access rights live. This is called Roles, and they are, basically, just named sets of access rights you can assign to users.
All these roles were created by the application developers. And our most important task for now is to reverse-engineer them so we could decide which user gets what roles.
Let’s open this FullRights role for example and see what’s inside. Here, on the top level of the tree, live the rights belonging to the application as a whole. These are administrative rights, rights to run different types of clients, a right to see who’s working with the system, etc.
As you can see the FullRights role has quite a bit of them, and whoever gets this role gets them all. Down the tree is where the Metadata Objects rights live. This, for example, is what the FullRights role can do with the Users catalog. Some of them look confusingly similar, like these Read and View, or Update and Edit guys. The thing is that some of them are DB access rights while others are interactive rights.
Let me show you. Let’s say I opened this form and want to see the users list. The Platform checks my database access rights and makes sure I have a right to read this Catalog. If I don’t, the Platform won’t even try to read the data from the database. But if I do, the data will be read, and then the Platform will check my interactive rights. If I don’t have the right to view this data, they won’t be shown to me, although the Platform can see and process them by executing some source code. If I do have the View right, the data will be passed to the form and shown to me.
So, these are the Metadata-Object-level rights. These ones are the database access rights, and these are the interactive ones. These object-level rights might be narrowed on the object structure level. For example, there might be restrictions for specific attributes, or tabular sections, or even a tabular section attribute. So, there might be access restrictions on the Metadata Object level, as well as on the attributes level.
Is there such a thing as a restriction on specific rows in the table? Of course, there is. Let’s open this EditCurrentUser role for example. This is its rights for the Users catalog. Anybody having this role can read and update any record as long as it meets this condition. Which effectively means the only record - the one belonging to this user. So, this is how the Roles work.
There is also a place where you can see the rights across all the roles. This is, for example, the same Users catalog with all the rights associated with it and all the roles up here. So, these are all the permissions there are. These were our Roles. Now let’s look at Users.
Users are not the part of the application, so they do not live here in the tree. You can find the users list up here under the Administration menu. Any user has a login, a full name and a bunch of other settings.
The most interesting ones live here on the Other page. This is where you can include the user in as many roles as you want. Which immediately brings up a question: what happens if there is a user included in several roles having contradicting permissions settings?
This is what. If any of the Roles has the permission, the user gets it too. If none of the Roles has it, the user doesn’t get it. So, this is how Roles and Users work in 1C:Enterprise.
What now? Should we just fill out the user list giving each one an appropriate set of Roles? No, we shouldn’t. Here is the thing. Besides this Platform-level user list we are in now, there is also the application-level Users catalog. It is here to store some additional application-specific information the standard Platform user list just does not have. It also has this InfobaseUserID attribute which will refer to the specific Platform user.
So, this application is built in such a way that every Platform user will have its counterpart in this Users catalog. Is every application you can stumble upon buit this way? Probably, not. But most of them are.
So, how do we fill out the user list anyway? This is how. I run the application without creating any Platform-level users in the Designer. Data initialization. But there is already the Administrator user in the drop-down list. This one was created by the application source code during the first launch. So, I’m going in without specifying any password. Another data initialization. And here we go.
Now. Somewhere in the application interface should be a place where I can fill out the user list. This Settings subsystem looks suspicious, so let’s check it out first. And here is the Users and rights settings. Going in, and this looks like the user list. In again, and here is the list with the only user - Administrator.
And there is all the additional information for this user living inside. Let’s add another user, like this. And now I can set up his access rights on this page. And this application level list looks so much simpler and more self-explanatory. Let’s add some of these to the user, save it, and see what happened to the Platform-level users.
I refresh the user list and here is the Administrator added by the application, and the user I added manually. Let’s open the last one and here are all the roles the application added to the user according to rather simple setting I’ve made using the UI. This is how we install an application and set up users and access rights.