users and groups separate for several solutions!

Discuss all feature requests you have for a new Servoy versions here. Make sure to be clear about what you want, provide an example and indicate how important the feature is for you

Re: users and groups separate for several solutions!

Postby pbakker » Tue Jul 28, 2009 9:53 am

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
pbakker
 
Posts: 2822
Joined: Wed Oct 01, 2003 8:12 pm
Location: Amsterdam, the Netherlands

Re: users and groups separate for several solutions!

Postby ptalbot » Wed Jul 29, 2009 3:57 am

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

pbakker wrote: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 wrote: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?
Patrick Talbot
Freelance - Open Source - Servoy Valued Professional
https://www.servoyforge.net
Velocity rules! If you don't use it, you don't know what you're missing!
User avatar
ptalbot
 
Posts: 1654
Joined: Wed Mar 11, 2009 5:13 am
Location: Montreal, QC

Re: users and groups separate for several solutions!

Postby Robert Huber » Wed Jul 29, 2009 10:59 am

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
Robert Huber
7r gmbh, Switzerland
SAN Developer
www.seven-r.ch
User avatar
Robert Huber
 
Posts: 1239
Joined: Tue Aug 23, 2005 6:52 pm
Location: Schaffhausen, Switzerland

Re: users and groups separate for several solutions!

Postby jcompagner » Wed Jul 29, 2009 5:16 pm

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.
Johan Compagner
Servoy
User avatar
jcompagner
 
Posts: 8829
Joined: Tue May 27, 2003 7:26 pm
Location: The Internet

Re: users and groups separate for several solutions!

Postby Robert Huber » Fri Aug 07, 2009 12:10 pm

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://<id-address>: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 wrote: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.
Robert Huber
7r gmbh, Switzerland
SAN Developer
www.seven-r.ch
User avatar
Robert Huber
 
Posts: 1239
Joined: Tue Aug 23, 2005 6:52 pm
Location: Schaffhausen, Switzerland

Re: users and groups separate for several solutions!

Postby ptalbot » Fri Aug 07, 2009 5:58 pm

How was it done before version 4 then?
Patrick Talbot
Freelance - Open Source - Servoy Valued Professional
https://www.servoyforge.net
Velocity rules! If you don't use it, you don't know what you're missing!
User avatar
ptalbot
 
Posts: 1654
Joined: Wed Mar 11, 2009 5:13 am
Location: Montreal, QC

Re: users and groups separate for several solutions!

Postby Robert Huber » Fri Aug 07, 2009 6:12 pm

Hi Patrick

It was the same.

Best regards, Robert

ptalbot wrote:How was it done before version 4 then?
Robert Huber
7r gmbh, Switzerland
SAN Developer
www.seven-r.ch
User avatar
Robert Huber
 
Posts: 1239
Joined: Tue Aug 23, 2005 6:52 pm
Location: Schaffhausen, Switzerland

Re: users and groups separate for several solutions!

Postby ptalbot » Fri Aug 07, 2009 6:16 pm

But there was no concept of workspace then, so how was it done?
How could you achieved what Johan is explaining here: managing different datasources/users/styles for different end clients??
Patrick Talbot
Freelance - Open Source - Servoy Valued Professional
https://www.servoyforge.net
Velocity rules! If you don't use it, you don't know what you're missing!
User avatar
ptalbot
 
Posts: 1654
Joined: Wed Mar 11, 2009 5:13 am
Location: Montreal, QC

Re: users and groups separate for several solutions!

Postby Robert Huber » Fri Aug 07, 2009 6:53 pm

Ah, I understand what you mean, but don't know how it was done as at that time we had only our first app in development. And wit one app the problem doesn't arise.

Regards, Robert

ptalbot wrote:But there was no concept of workspace then, so how was it done?
How could you achieved what Johan is explaining here: managing different datasources/users/styles for different end clients??
Robert Huber
7r gmbh, Switzerland
SAN Developer
www.seven-r.ch
User avatar
Robert Huber
 
Posts: 1239
Joined: Tue Aug 23, 2005 6:52 pm
Location: Schaffhausen, Switzerland

Re: users and groups separate for several solutions!

Postby david » Mon Aug 10, 2009 10:45 pm

ptalbot wrote:How was it done before version 4 then?


This was how it was done in 3.5 (article is 1.5 years old and targeted to our frameworks developers). It is done the same in 4.x with workspaces. It works simple enough for us -- we literally have dozens of workspaces and sharing (and versioning!) is MUCH easier than in 3.5. Of course, we have our own security module so don't use Servoy's default security stuff which makes things a lot simpler. In my opinion, if you're running multiple clients from one server you should roll your own SaaS-level security. Servoy's security is a pain for managing more than a few users at a very basic level.

Code: Select all
MANAGING ALL OF YOUR SERVOY SOLUTIONS
==============================

What's inside:

   1) How did this happen?
   2) The Problem
   3) Solution and benefits
   4) How to implement
   5) Summary
   6) Bonus

1) How did this happen?

Servoy is an amazing tool for solving problems. So much so that it is common to find yourself with a repository packed with a sundry of solutions. An Filemaker Pro data importer, an HTML method colorer, an batch mail solution, the main project for your company, a simple solution to track all of the pin whole leaks you've fixed in your house this past year, etc. (I was even working on a Tetris game at one point.)

Then there are all the random solutions with weird names like "ztest", "trashme" and "tempxyz" littering up the place. Not that you can delete any of them in case one of them contains that all important code snippet you've been looking for for the past 20 minutes.

Then there was that annoying Servoy bug several months ago that you couldn't quite isolate after repeated postings to the forum and several trips to the drug store for the little rage pills. You finally get a working non-working example put together in a nice tidy solution that you sent off to Servoy support. This solution was called, "seeitoldyouso." In the process you also created solutions "imnotsureifthisisit" and "whywontthisbugshowupnow".

Then there was a point when you figured you were finally hot stuff at Servoy and you decided to start answering forum questions. But you weren't quite confident enough to answer without a little testing of your own first. These solutions are typically named "igotdaanswer", "thatdudeissostupid", "toosimple", etc. (The day you accidently stuck your own foot in your mouth you don't celebrate by creating a solution called "imsuchanidiot".)

Then you decided one day to split "the main project for your company" into modules in an attempt to organize that solution better. You end up putting the navigation in the wrong module, spend days trying to figure out which modules to include in each other, and forget one morning before coffee which module opens the whole solution...but we can save all this for another tip. The end result: a bone collection of modules -- some working, some just hanging out and making your life miserable by luring you into opening them by mistake. Repeatedly. Sucker.

Of course you have also been faithfully doing the version release thing all along as well. This leads to the always fun: "I know I made that screen in module x of solution y. Now let me see...what release was that in...."

2) The problem

The Servoy repository screen is an alphabetical listing of all your solutions. That's it. You don't get to reorder them, categorize them, describe them, or take a peak into the contents without opening them. At one point, Servoy started putting the date beside each release (I think it was version 3.something). Given the magnitude of how limited the functionality of the Servoy repository screen is, this tidbit practically made me suffocate from laughing the day I noticed it.

3) Solution and benefits

A. Divide your solutions up

My Servoy life became orders of magnitude easier the day I started dividing my solutions into their own instances of Servoy. Put all of your testing apps in one instance, some utility apps in another, the solution that runs your website in another, all of your client solutions each in their own instance, etc.

The main reason we recommend installing Frameworks into a new repository is because it currently weighs in at 13 modules (and we still have a few more to go in the base release). Simple put, we don't want you to add all those modules into a repository with other important stuff -- it will just confuse your life.

B. Use naming conventions

This is almost a requirement if you are using modules. Any naming convention is better than nothing. Something, anything -- to organize the repository list so you don't have to go hunting around to find the module you want to work on.

We go one step further and put a short unique identifier tag into each module name (in CAPS). We use this identifier to preface all object names in that module that so that there is no chance of getting conflicting names when we combine various modules. Forms, calculations, relationships, value lists, global variables, etc.

C. Versioning

I keep releases to a bare minimum. You can't edit past releases, it's impossible to tell which release has what in it, you can't compare releases, and rolling back a solution with 15 modules is pain. The only reason I have releases is when I import modules I get back from other developers on a project.

Instead, I keep multiple snapshots of a client solution -- each in their own repository. Besides being easier to identify what version does what, I can open multiple versions at the same time and compare differences.

D. Point multiple instances of Servoy developer to the same repository

Do this one as needed. In my case I do this all the time! Why? So I can work on multiple modules (and even different screens in the same module) simultaneously.

Say I need to create a report in the report module. The requirements may be to add another field to a table. At the same time I will want to add this field to the work flow module that handles data entry for this table.

When using this technique, just restart both Servoy developer instances often to sync up the changes.

4. How to implement

When I started writing this tip I had no idea I would write so much before getting to this point. But it all just poured out! Which is to say that what follows is very simple once you get the hang of it and well worth doing over and over until you can set up a new instance of Servoy in under a minute.

Here are the steps:

   1. create new databases
   2. duplicate Servoy developer application
   3. duplicate servoy.properties file
   4. assign new servoy.properties file to new Servoy developer application
   5. re-point your database connections to the new databases

1. Create new databases

Typically you will have a repository database and a database for your solution data. When using our frameworks also have a frameworks and example databases. (The Servoy default install has a few more as well.)

I use the free Mysql Administrator application for this job. Whatever your backend flavor is, get an external tool to manage it with. You cannot create new databases from within Servoy.

Again, using a naming convention for your databases is a good thing. "client1_repository" and then "client2_repository" for the next version makes things simple.

2. Duplicate Servoy developer application

Just duplicate in place and rename it. "Client1" or whatever.

3. Duplicate servoy.properties file

Same thing. Call it client1.properties.

4. Assign properties file to a Servoy developer

By default, Servoy developer keeps all of it's properties in the servoy.properties file. If you duplicate Servoy developer, the duplicated application is still pointing to the servoy.properties file. This is a good thing if you want to run two developers on the same solution (benefit D above).

How to do this varies by platform. Check out this post by Edward Callaghan on Servoy Magazine. For windows users, read the comments:

http://www.servoymagazine.com/home/2005/05/tip_how_to_run_.html

What isn't covered in this post is that you can also rename the "Servoy" string in the title bar to anything you want -- say, "Client1". Which makes it easier to identify which developer instance you are on when you have 5+ of them open.

It's in this section of the plist file:

   <key>CFBundleName</key>
   <string>Servoy</string>

5. Re-point database connections

At this point, when you start up your new developer you are still pointing to the databases that your source properties file was pointing to (since you duplicated it). Go into Servoy preferences and re-point things and restart. If you changed the repository connection to a new database you will be prompted to rebuild the repository tables.

Now you have a blank slate to work with. Easy beans.

5. Summary

Servoy's repository screen still has a lot evolving to do. If you are working on many solutions you gain a number of benefits by separating your solutions into multiple repositories. Not the least of which is keeping better organized!

You can also use this technique to do basic versioning and develop in multiple related modules (or even the same module) at the same time.

6. Bonus

If you want to go to the next level of version control, check out Jeff Bader's comment (1st one) to this Servoy Magazine post:

http://www.servoymagazine.com/home/2007/12/commentary-serv.html
David Workman, Kabootit

Image
Everything you need to build great apps with Servoy
User avatar
david
 
Posts: 1727
Joined: Thu Apr 24, 2003 4:18 pm
Location: Washington, D.C.

Re: users and groups separate for several solutions!

Postby ptalbot » Tue Aug 11, 2009 6:52 pm

david wrote:This was how it was done in 3.5 (article is 1.5 years old and targeted to our frameworks developers)...

Hi David!
Thanks for sharing, that's great info. I'm convinced that a separate workspace is the way to go now.

Actually, I was already using a separate worskpace for tests and explorations of all kind (it often ends up being my "main" workspace these days ;-)), but that was more of a convenience, to allow for the wildest (especially with beans and plugins), but I really believed that one for test and one for work would be enough, although I was concerned at how easily it could grow up...
Having some solutions Working Sets would be nice BTW, and maybe some way to organize the forms of a solution in a folder hierarchy.

About security though, I'm actually thinking of (starting to craft) some kind of hybrid model (where I roll my own model of users/roles based on independant tables and attach it to Servoy's groups to benefit from some of Servoy's security features).
I remember seing Sean Devlin's webinar about it and thought it was actually nice to be able to leverage some part of the built-in security while fine tuning your own.
Patrick Talbot
Freelance - Open Source - Servoy Valued Professional
https://www.servoyforge.net
Velocity rules! If you don't use it, you don't know what you're missing!
User avatar
ptalbot
 
Posts: 1654
Joined: Wed Mar 11, 2009 5:13 am
Location: Montreal, QC

Re: users and groups separate for several solutions!

Postby david » Tue Aug 11, 2009 7:59 pm

ptalbot wrote:About security though, I'm actually thinking of (starting to craft) some kind of hybrid model (where I roll my own model of users/roles based on independant tables and attach it to Servoy's groups to benefit from some of Servoy's security features).
I remember seing Sean Devlin's webinar about it and thought it was actually nice to be able to leverage some part of the built-in security while fine tuning your own.


That was a really good webinar (as usual Sean).

The two main issues with touching Servoy security is:

1- Data entry in design mode -- severely limits runtime flexibility.
2- Permissions logic can get really buried -- what layouts and layout objects are visible, editable; what tables can be deleted from, etc. Spaghetti code in your future.

Keep in mind that there is nothing in Servoy security that you can't do on your own. I agree with you that the advantage of the hybrid model is that you can save time coding specific logic at the group level (i.e. table logging or whatever). But you have to do a lot of interface work for the data structures and code in all the hooks which is a fair jump from just using Servoy security.

If you're in the business of developing many Servoy solutions, or you need ultimate flexibility and power -- eventually you have to go all the way. It's much easier to build business logic around group permissions and everything is configurable at runtime. For large solutions, deployments, or SaaS it's almost a requirement. And once you've got it all done (reusable of course), small deployments and solutions are a snap.

An example: our clients can easily setup a temporary employee with what screens are visible, what records are available, what actions can be done, and tons of other things. No calling us.

A benefit: with this in place, new projects are literally confined only to developing business logic. Clients like paying for their business logic to be developed more than for solution infrastructure to be developed.

Another benefit: no issues syncing developer machines with deployment servers.

So depending on what your goals are -- default, hybrid, or completely custom security -- have their place. However, I'll put a bet down that you will eventually end up with a completely custom security scheme Patrick :) It's almost inevitable once you start down that road.
Attachments
Picture 9.png
Picture 9.png (162.05 KiB) Viewed 8096 times
Picture 10.png
Picture 10.png (161.66 KiB) Viewed 8101 times
David Workman, Kabootit

Image
Everything you need to build great apps with Servoy
User avatar
david
 
Posts: 1727
Joined: Thu Apr 24, 2003 4:18 pm
Location: Washington, D.C.

Re: users and groups separate for several solutions!

Postby ptalbot » Tue Aug 11, 2009 8:32 pm

david wrote:So depending on what your goals are -- default, hybrid, or completely custom security -- have their place. However, I'll put a bet down that you will eventually end up with a completely custom security scheme Patrick :) It's almost inevitable once you start down that road.

You are right as usual David! :D I will probably end up with custom.

In the meantime, it saves some times to rely on the existing instead of adding this to the amount of things I need to build...

But I'm aware that one day or another, it will prove insufficient. I just hope that I will have the time then (meaning budget) to do it.
If only I could have the fundation of a framework that I know of... :wink:

Thanks for your explanations and nice screenshots!
Patrick Talbot
Freelance - Open Source - Servoy Valued Professional
https://www.servoyforge.net
Velocity rules! If you don't use it, you don't know what you're missing!
User avatar
ptalbot
 
Posts: 1654
Joined: Wed Mar 11, 2009 5:13 am
Location: Montreal, QC

Re: users and groups separate for several solutions!

Postby david » Tue Aug 11, 2009 8:50 pm

ptalbot wrote:If only I could have the fundation of a framework that I know of... :wink:


We had a $50 special running but it expired yesterday... :twisted:
David Workman, Kabootit

Image
Everything you need to build great apps with Servoy
User avatar
david
 
Posts: 1727
Joined: Thu Apr 24, 2003 4:18 pm
Location: Washington, D.C.

Re: users and groups separate for several solutions!

Postby Thomas Parry » Wed Aug 12, 2009 1:58 pm

I use Data-Mosaic's Framework for user and security (access to forms and records) and it is great. So maybe try it out for a test drive, the investment is worth it in terms of payback of time saved developing and testing (believe me I tested it a lot.) :roll:
Waiting expectantly for the 4.x version now...
Tom Parry
Prospect IT
Java/C++/Servoy/Jasper Reports/Simulation/Service Applications
http://www.prospect-saas.biz
Thomas Parry
 
Posts: 498
Joined: Thu Jan 10, 2008 8:48 pm
Location: Ottawa, Canada

PreviousNext

Return to Discuss Feature Requests

Who is online

Users browsing this forum: No registered users and 8 guests