users and groups separate for several solutions!

Classic Servoy
1

Hello,

I’m developing and modificating several solutions for different customers (companies). Every solution has it’s own users and groups and admin user account with different passwords to the other solutions. It is not nice to have only users and groups in the global editor of Servoy Developer. It nerves that I have to synchronize all users and groups of all my solutions for Team Support and repairing different usernames and passwords of the solutions.
I would like to have an User/Group Editor for each solution separately!

Thomas Schnaus

Servoy 4.1.3

2

Best to use different workspaces per (group of) solutions for which you manage users and groups.

Security info is manager in the Resources project and of those you should have just one in your workspace (best practise).

Paul

3

Hi Paul,

I don’t think that is “best practise”! Maybe a workaround for single (local) developing.
When I make a checkout on my local machine from the team support remote server, Servoy is automatically creating a new direction (folder) for the solution and modules in the servoy_workspace direction. So I have all created useres and groups from all checked out solutions in the security. And there I don’t see what user and group is belonging to a solution.

Thomas Schnaus

4

Users and groups do not belong to a solution, but to a environment, just like styles and most table and column info.

This info is shared between different solutions, thus inside your local workspace it’s stored in a separate “project” called the resources project.

If you want to work on different solutions with different settings in groups and users, you need to have separate resources projects and link the appropriate resources project to your solution.

Best practise is just to have 1 resources project per workpsace.

Paul

5

Hello Paul

As Eclipse and Serclipse itself stores on Checkout everything in THE workspace (servoy_workspace) and separates it automatically WITHIN the workspace, it seems to me unlogical and working against the Eclipse tool to follow your advice of using separate workspaces. I mean this can be a short term workaround but doesn’t compensate for the fundamental flaw that users and groups belong really always to a solution (application) and not to an environment (logically spoken), in Servoys case even to a development environment. In part it also may have to do with the “old” concept of main and modules, which are still not clearly separated (Servoy calling the main type normal and modules type module), the modules should be in the folder of the main and not on the equal level.
It makes me feel a bit unsave what are Servoys ideas regarding users and groups, but I made always the assumption for myself, Servoy is going to coorect these things in a future version - may be my assumption is wrong. I then would like to make a case for it and know how others see/handle this problem, but to me it’s quite fundamental and in the current form wrong.

Best regards, Robert

pbakker:
Users and groups do not belong to a solution, but to a environment, just like styles and most table and column info.

This info is shared between different solutions, thus inside your local workspace it’s stored in a separate “project” called the resources project.

If you want to work on different solutions with different settings in groups and users, you need to have separate resources projects and link the appropriate resources project to your solution.

Best practise is just to have 1 resources project per workpsace.

Paul

6

Let’s go back a step: when you deploy your solution, you do so on an environment. This environment has 1 set of users and usergroups, regardless how many solutions you host on it.

So, back to development: per environment for which you develop, you ought to have 1 resources project containing stuff specific to that environment.

Then, the best practise is to use separate workspaces for each environment, so you have only 1 resources project per workspace, but if you want to do it differently, feel free to do so.

Now lets put the following into the mix: if you develop a solution that you host on multiple environments (== multiple application servers), you should only have in your resources project what is shared among those environments, to typically not the users and maybe the usergroups (depending if the developer defines the groups of new groups can be created in the deployment environment). In such scenario, because everything in the resources project is shared among all environments, you ofcourse just need 1 workspace with one resources project.

all of the above is valid if you use Servoy’s built-in user and usergroup mechanism. If you roll your own, for which you have all the functionality exposed to do so, you can ofcourse implement it any way you like, like having users and groups specific for a certain application.

BTW: modules are not to be included inside their parent, because they do not depend on the parent and they can even have multiple parent, since you can re0use modules. So including under their parent limits their usefulness severely.

Paul

7

Hello Paul

Thanks for detailing the aspects. Following what I think/found:

pbakker:
Let’s go back a step: when you deploy your solution, you do so on an environment. This environment has 1 set of users and usergroups, regardless how many solutions you host on it.

So, back to development: per environment for which you develop, you ought to have 1 resources project containing stuff specific to that environment.

Is this Servoys official view? And how do I see and manage the users per environment in Servoy Server Administration? I only see all users there at once without differentiating between an environment (as you call it) or what I would expect per Application, i. e. (Main) Solution in Servoys term. What do I do when I have same user names in one environment and in another one but they are not the same persons? If a customer likes to have a username I can’t tell him he can’t use it because it’s already used by another customer we are developing for…

pbakker:
Then, the best practise is to use separate workspaces for each environment, so you have only 1 resources project per workspace, but if you want to do it differently, feel free to do so.

Sorry, I wouldn’t call it best practice, it’s more of a workaround for me. If I do a checkout for a second project, i. e. solution, Serclipse doesn’t ask for another workspace but put’s the solution directly into servoy_workspace.

pbakker:
Now lets put the following into the mix: if you develop a solution that you host on multiple environments (== multiple application servers), you should only have in your resources project what is shared among those environments, to typically not the users and maybe the usergroups (depending if the developer defines the groups of new groups can be created in the deployment environment). In such scenario, because everything in the resources project is shared among all environments, you ofcourse just need 1 workspace with one resources project.

Yes, I would like not to make our own thing, if something already exists. BTW, how does the Servoy usr and usergroups work when using Open Directory or Active Directory?

pbakker:
all of the above is valid if you use Servoy’s built-in user and usergroup mechanism. If you roll your own, for which you have all the functionality exposed to do so, you can ofcourse implement it any way you like, like having users and groups specific for a certain application.

As said above, it would be nice to use Servoys built in functionality.

pbakker:
BTW: modules are not to be included inside their parent, because they do not depend on the parent and they can even have multiple parent, since you can re0use modules. So including under their parent limits their usefulness severely.

Paul

That’s ok, but the problem is one doesn’t see the dependencies in any way outside Serclipse.

What I propose is a clean separation/assignment of users and groups to a (main) solution, i. e. an application which is after development deployed to a customer. I remember Jan Blok said this is going to happen for a version in the future.

Best regards, Robert

8

Hi all!

First, I’m sorry to disagree with Robert about the fact that “the modules should be in the folder of the main and not on the equal level.”
That goes against the idea that a module is something that can be shared among many solutions… if you enclose it into one solution, you won’t be able to use it anywhere else.
But then the all idea of “module” doesn’t make sense anymore, because a solution tagged as “solution” can be used as a module in any case…
I must confess that I never made any “module” as such, although I use them a lot :)

About security though, I do agree with you, Robert: I wonder about these best practices too!

What is very much unclear to me is the role of the Servoy Resources Nature that you can assign to a solution, and the fact that you can also change/create Resources project on the fly in Serclipse.

I would have thought that a “Resource Nature” project was where Servoy was keeping its Datasources, Security, and Styles, at least that’s what I can understand when I look in the workspace at a “Resource” project (the default “servoy_localhost_resources” for example, with a .project file set with a nature of “com.servoy.eclipse.core.ServoyResources”), so why having them in different workspaces altogether, when/if you can choose/change/assign them from inside the same Workspace to different solutions?
Pauls, by recommending to use one workspace per solution “Resource Nature”, are you implying that this feature is not working?

And even more confusing, there is the relationship between these “Resource Nature project” and the Servoy repository…
This is still very mysterious to me, and I feel that I’m not the only one.

Questions, questions…
This is an area which definitively needs some cleaning, and precise documentation, and I also hope that it will be addressed in the next major release.

9

+1 on the need for clarification of the relationship between Resources and Workspaces…

And should Solutions and Modules both simply become "components’?

10

ptalbot:
Hi all!

First, I’m sorry to disagree with Robert about the fact that “the modules should be in the folder of the main and not on the equal level.”
That goes against the idea that a module is something that can be shared among many solutions… if you enclose it into one solution, you won’t be able to use it anywhere else.
But then the all idea of “module” doesn’t make sense anymore, because a solution tagged as “solution” can be used as a module in any case…
I must confess that I never made any “module” as such, although I use them a lot :)

Hi Patrick, you don’t need to be sorry .-) a forum is good to hear many (different) ideas. But I actually didn’t mean grouping into one “package” means one cannot use modules in different solutions - of course I also would like to use modules in more than one solution if appropriate (although in our practice it’s quite rare, as solutions have not much in common, so the chance of using modules is not big, except for modules containing basics)

ptalbot:
About security though, I do agree with you, Robert: I wonder about these best practices too!

What is very much unclear to me is the role of the Servoy Resources Nature that you can assign to a solution, and the fact that you can also change/create Resources project on the fly in Serclipse.

I would have thought that a “Resource Nature” project was where Servoy was keeping its Datasources, Security, and Styles, at least that’s what I can understand when I look in the workspace at a “Resource” project (the default “servoy_localhost_resources” for example, with a .project file set with a nature of “com.servoy.eclipse.core.ServoyResources”), so why having them in different workspaces altogether, when/if you can choose/change/assign them from inside the same Workspace to different solutions?
Pauls, by recommending to use one workspace per solution “Resource Nature”, are you implying that this feature is not working?

Thanks Patrick for explaing this in more detail, but that’s a part which shows that one has either the concept as it it is now or one has strictly separated workspaces with it’s own resources etc., but then, I assume, the easy way of activating different solutions with all of the associated stuff would get lost.

ptalbot:
And even more confusing, there is the relationship between these “Resource Nature project” and the Servoy repository…
This is still very mysterious to me, and I feel that I’m not the only one.

I agree, I am still missing a documentation about the concept of how Servoy is intended. Unfortunatly, this is not only a flaw of Servoy , everyone tends to write about which button to press etc. but nowhere are the intentions, concepts, ideas, current state and what will come and how it should look in “the end”, which would help a lot to understand the ideas behind the tool as a whole. May be I again I could ask at this moment for a sheet describing all the events and their relationships to each other and when the trigger in various circumstances, incl. when using modules ,-) And yes, I know, the onShow event for example triggers when the form is shown .-) (if it would be only that easy)

ptalbot:
Questions, questions…
This is an area which definitively needs some cleaning, and precise documentation, and I also hope that it will be addressed in the next major release.

According to my reply, for me as well, questions, questions, … these sort of questions also show the limit of a forum to discuss them, as no one has the big picture, or, more precisely said, at least not me.

Of course despite my complaints/wishes many thanks for the discussion possibilities on the forum! Robert

11

Let me try to explain the Resources project once more:

A Resources project is a project in your workspace containing all the info Servoy needs to operate, but which isn’t specific to a certain solution/module. These are things like stylesheets and most table and column info.
Solutions/modules need to be connnected to 1 Resources project, to get the required info in tables and columns for example.
When you export a Solution, the export will contain a complete definition of the datamodel it requires. This is taken from the Resources project.
When you deploy your solution on a Servoy Application Server this datamodel info contained in the solution export is used to create/update the datamodel of the Servoy Application Server.

It’s best practise to have only 1 Resources project per workspace to avoid making mistakes like having the solution linked to 1 resource project and one of it’s modules linked to another resources project.

@Patrick: The suggestion to have only 1 Resources project per workspace is a “best practice”, not something you must do because it wouldn’t otherwise work (then it wouldn’t be a “best practise”).

@Robert:

And how do I see and manage the users per environment in Servoy Server Administration

: What you see on the admin pages always only belongs to 1 environment (== Servoy Application Server), thus 1 Resources project

BTW, how does the Servoy usr and usergroups work when using Open Directory or Active Directory

If you want to use external systems for user management and/or validation, you make use of all the scriptable parts of the built-in Security to hook things up, of you completly roll your own.

Paul

12

Hi Paul

Thanks for explanations, I think I understand what you say but I don’t get it.
You are saying it’s best practice to have separate resources project per workspace, ok. But Servoy by default puts on Checkout everything into one folder, why, if best practice is just the opposite?
And, if I use your proposed 1 resources project per workspace attempt, how do I set up an application server for each workspace?
I mean, for any real project this is then the only way to go, you normally surely don’t want to have users from one project mixed up with users from another project, do you?
Is the setting up of your proposed 1 resources project per workspace descibed anywhere in the Servoy docu? Can you please point me to it?

Somehow this is still all very contradictory to me, but may be I am the only one. But what I sure can’t live with, i. e. my customer can’t live with, is having other users mixed in his solution. I have no clue how other handle that, but it’s sure a standard situation.

Robert Huber:

And how do I see and manage the users per environment in Servoy Server Administration

: What you see on the admin pages always only belongs to 1 environment (== Servoy Application Server), thus 1 Resources project

BTW, how does the Servoy usr and usergroups work when using Open Directory or Active Directory

If you want to use external systems for user management and/or validation, you make use of all the scriptable parts of the built-in Security to hook things up, of you completly roll your own.

As far as I understand you, this means I can not use the (Servoy) built in Users/Groups Editor but I have to program everything with the methods offered under security?

Best regards, Robert

13

Robert,

If you manage users from within your development environment, then in order to have separate groups of users per project/application/environment, you need to have separate resources projects and when working with multiple resources projects, the “best pratcise” is to use separate workspaces, but feel free to do otherwise.

At deploymenttime (not being development), the Servoy Application Servoy just has one set of users/usergroups and they are shared between all solutions you host on that Servoy Application Server. If you don’t want that, you have all the functions/tools/API etc. at your disposal to create whatever user/usergroups mechanism you want.

And, if I use your proposed 1 resources project per workspace attempt, how do I set up an application server for each workspace?

the admin page of your development instance will alway have the user/usergroup info of the Resources project linked to the active solution in Developer.

You are saying it’s best practice to have separate resources project per workspace, ok. But Servoy by default puts on Checkout everything into one folder, why, if best practice is just the opposite?

No, you decide first on which project you want to work, open the appropriate workspace etc etc. Team Providers in Eclipse (SVN, Servoy Repository, CVS, etc.) always check out into the active workspace.

I mean, for any real project this is then the only way to go, you normally surely don’t want to have users from one project mixed up with users from another project, do you?

I wouldn’t have my users defined in my developer environment anyway.

Paul

14

pbakker:
@Patrick: The suggestion to have only 1 Resources project per workspace is a “best practice”, not something you must do because it wouldn’t otherwise work (then it wouldn’t be a “best practise”).

Hi Paul, I understand about the general meaning of “best practices”, but when these best practices induce more trouble to than benefits (because you cannot easily share modules, copy/paste from one project to another, etc…), and when there is clearly another way of doing things (using Resource Nature and assigning them to specific projects), I can’t help but wondering why you recommand it.

Saying it is “best practice” doesn’t say at all why doing it differently is wrong or what could possibly go wrong when doing it differently.
So what we’d like to know is what is wrong with having different Resource Nature projects in a single workspace, one for each project?

15

pbakker:
I wouldn’t have my users defined in my developer environment anyway.

So what you are saying is that for a server with multiple solutions (for different clients), the groups will need to be the same for all solutions, and then you roll your own table of users inside each solution (with a user management of your own).

That’s the mixed security approach, if I remember from your webinar on security, isn’t it?

16

Saying it is “best practice” doesn’t say at all why doing it differently is wrong or what could possibly go wrong when doing it differently.
So what we’d like to know is what is wrong with having different Resource Nature projects in a single workspace, one for each project?

If you have multiple Resources projects in your workspace, using different onces for different projects (==solution/module), the likelyhood of including a module into a solution that is attached to a different Resources project that the parent if far greater.

If you create separate workspaces you can still reuse modules: just check them out in each workspace where you need it.

So what you are saying is that for a server with multiple solutions (for different clients), the groups will need to be the same for all solutions, and then you roll your own table of users inside each solution (with a user management of your own).

That’s one of the many possible combinations you could think of.

Paul

17

Hi Paul!
Thanks for your patience, these concepts are not at all obvious in Servoy, I’m afraid.

pbakker:
If you have multiple Resources projects in your workspace, using different onces for different projects (==solution/module), the likelyhood of including a module into a solution that is attached to a different Resources project that the parent if far greater.

So that it is the main argument you have when you recommand to use different workspaces, isn’t it?

pbakker:
If you create separate workspaces you can still reuse modules: just check them out in each workspace where you need it.

When you say that it implies that there is only one repository for many workspaces, is that correct?
But if you check out a module in a workspace coming from another workspace, will it not be linked to the Resources of the “other” workspace? Will that not introduce the same “likelyhood” of the problem you are talking above?

18

Hello Paul, All

I still think we are not talking on the same “line”. I try again to explain where I see the current users and groups concept not sufficient or wrong. What you are saying about getting the “correct or desired” result is one has to set up a correct, i. e. corresponding workspace to achieve the desired result concerning users and groups. These are indirect assignements/dependencies to achieve a desired result. What I need is a direct, i. e. somewhere directly readable assignment of users and groups to solutions/modules. Defining correct users and groups via setting up corresponding workspaces is conceptually a wrong concept for me. Such a concept is always hard to understand, hard to read and error prone, because,

  • every developers workspace needs to be in sync (structure wise) with the workspaces of all other developers, otherwise error can and will happen
  • what if more than 1 developer works on a solution? One has to make sure any developer has locally the same workspace which she/he is commiting to a common repository the solution is developped
  • what if another developer is checking back in the (server) repository another soultion which has some same user names and groups but associated to a completely other solution, as an example the admin user. This users has to be in the repository (not deletable) but has with one customer password ‘ab’, but with another customer password ‘cd’, and so on. Are you then saying one need a separate repository for each customer? And I need these information because I have to setup, develop, and test in an environment as close as possible to the customers environment
  • who or what would be the the master when exporting a solution from the development server repository?

I mean, no one would implement the assignment of modules to a main solution via some sort of file structure on a local development machine, for example, no there has to be a possibility to directly assign modules to a main.

It’s difficult to describe the whole context but I hope it gives an idea what I mean. To me, there is only one chance to get it right: A possibility to explicitly define which users and groups belong to which solution/modules, and that information has to be in the server repository. And as the repository has all the info about the main solution and the modules and which form belongs to which module etc. everything is there, one needs “just” the forms/functionality to make the assignments.

Thanks and best regards, Robert

19

Guys,

do you want to know how many workspaces i use for my java development?
about 7…

Why? Because (and there are open bug reports on this for quite some time on bugzilla of elcipse) eclipse doenst know the concept of a “solution”
which is a super project over projects. That would be very nice to have. This way you can group projects that belong to each other and have the same name as another project
thats under a different super project/solution.

But because eclipse cant do that (yet) we use workspaces to separate the project sets that belong to each other. Thats why i have about 7 workspaces…

Thats why paul calls it also best practice to use 1 resource project per workspace and use different workspaces per “super project”

A super project you have to see as a customer of yours. You have 2 customers that both have a completely different set of resources (tables and styles and users)

Then for both customers you have 1 workspace each where you have checkout the resource project of the specific customer.

This does NOT mean that you cant use the same modules for the different customers! Just check it out on both, and if you have naming convention for your resource project then the module
just maps in each workspace on a different resource project, ofcourse you need to make sure that the tables/columns and styles that the module uses are in both,
but this is logical because on if you would really use that module also on both of your customers appservers you also copy/import all that info.

Also this way of developing you can have for customer 1 version X (a branch) of module checked out and for customer 2 you just use trunk of that module.
Because if you would change that module in customer 2 who tells you that customer 1’s solution doesnt break?

For the most part i see shared modules over multiply customers more as read only libraries (just like jars in java you dont edit them you use use them)
if they arent you need to be careful anyway.

The setup i described above is much harder to get right in 1 workspace.
Because for 2 customers that has there own app servers (different resources) you need to have 2 resource projects in one workspace and a module can only have 1 of them
then you cant add that module to the solution because that will give you a error that the modules resource project != solutions resource project.
So 2 workspaces are you only real good option for this setup.

20

Hi Johann

Thanks for detailling this subject. I still have the impression, we are in parts talking about different things. I am talking about the servoy admin menu Users, located here: http://:8080/servoy-admin/user

At this place, I would like to assign users to a solution. And that’s a pure Servoy matter (as far as I can see), and the good thing is, Servoy knows what a solution is and can therefor make an assignment to it, independantly of any workspace.
I mean, the way it is now is just an implicit assignment to all solutions (i. e. if a group and its users are used within a solution).

Or am I missing something?

Best regards, Robert

PS: But yes, I got the message that you are not going to put this functionality into the next few releases .-) although I hope so :-)

jcompagner:
Guys,

do you want to know how many workspaces i use for my java development?
about 7…

Why? Because (and there are open bug reports on this for quite some time on bugzilla of elcipse) eclipse doenst know the concept of a “solution”
which is a super project over projects. That would be very nice to have. This way you can group projects that belong to each other and have the same name as another project
thats under a different super project/solution.

But because eclipse cant do that (yet) we use workspaces to separate the project sets that belong to each other. Thats why i have about 7 workspaces…

Thats why paul calls it also best practice to use 1 resource project per workspace and use different workspaces per “super project”

A super project you have to see as a customer of yours. You have 2 customers that both have a completely different set of resources (tables and styles and users)

Then for both customers you have 1 workspace each where you have checkout the resource project of the specific customer.

This does NOT mean that you cant use the same modules for the different customers! Just check it out on both, and if you have naming convention for your resource project then the module
just maps in each workspace on a different resource project, ofcourse you need to make sure that the tables/columns and styles that the module uses are in both,
but this is logical because on if you would really use that module also on both of your customers appservers you also copy/import all that info.

Also this way of developing you can have for customer 1 version X (a branch) of module checked out and for customer 2 you just use trunk of that module.
Because if you would change that module in customer 2 who tells you that customer 1’s solution doesnt break?

For the most part i see shared modules over multiply customers more as read only libraries (just like jars in java you dont edit them you use use them)
if they arent you need to be careful anyway.

The setup i described above is much harder to get right in 1 workspace.
Because for 2 customers that has there own app servers (different resources) you need to have 2 resource projects in one workspace and a module can only have 1 of them
then you cant add that module to the solution because that will give you a error that the modules resource project != solutions resource project.
So 2 workspaces are you only real good option for this setup.