By Jeff Pagley - 10/7/2010
I started my database by using a copy of the Strataframe Example database which had the Security tables. I open the Security Dialog box through code (see below). The editor allows me to add/edit users and roles, but not permissions. What is wrong?
Program.cs Code:
System.Data.SqlClient.SqlConnectionStringBuilder builder = new System.Data.SqlClient.SqlConnectionStringBuilder();
builder.DataSource = "1LPJPAGLEY\\SQLEXPRESS";
builder.InitialCatalog = "CEI";
builder.UserID = "sa";
builder.Password = "access";
DataLayer.DataSources.Add(new SqlDataSourceItem("", builder.ConnectionString));
//Set the data source key for the security tables
SecurityBasics.SecurityDataSourceKey = "";
Form Code:
MicroFour.StrataFrame.Security.SecurityDialog frm = new MicroFour.StrataFrame.Security.SecurityDialog();
frm.ShowDialog();
Thanks,
Jeff
|
By Trent L. Taylor - 10/7/2010
You are not allowed to add or edit permissions at run-time by default, only at design-time. It doesn't make sense for the end-user to create their own permissions as you the coder, have to implement the permissions in the application. For example, if you create a permission named "LetMeIn", you as the developer have to implement that permission in your code logic someplace to be useful. In this example, let's say it is a form, so you would have to open your form in the designer and set the security permission to "LetMeIn." Once you compile and run, the form knows to look and test on that permission.
Technically you can call the SecurityDialog and have it allow permissions, but it really doesn't make any sense. But to show the permissions and the restriction sets, you would do this:
C#
MicroFour.StrataFrame.Security.SecurityDialog securityForm = new StrataFrame.Security.SecurityDialog(true, true);
securityForm.ShowDialog();
VB.NET
Dim securityForm As New MicroFour.StrataFrame.Security.SecurityDialog(True, True)
securityForm.ShowDialog()
|
By Jeff Pagley - 10/7/2010
Hi Trent,
Yes, I understand why the permissions are not available to add/edit to the end user. However, I am trying to setup the initial permissions in the security tables in my database during my development. I added the (true, true) parameter values. It still does not allow me to add/edit the permissions!?!?
Also, the other reason why I need this ability is I am going to need to be able to allow an administrator to add permissions for future updates of the software at a remote site. How does other developers handle adding permissions to their databases once the app and database has been deployed?
Thanks,
Jeff
|
By Trent L. Taylor - 10/7/2010
Are you going into the Security Editor through Visual Studio?
- Open Visual Studio
- Click StrataFrame -> Role Based Security Editor
If you are not working off of a project then the permissions can't be shown. The only way to work off of a project in this case to add permissions is through VS.
|
By Jeff Pagley - 10/7/2010
OK. Then how do I point the IDE RBS Editor to the security tables in my database instead in the Strataframe database?
Jeff
|
By Trent L. Taylor - 10/7/2010
Jeff,
How are you developing? It is generally not a good idea to work off of your production or distribution database. The easiest and best way is to let the DDT do it for you. It will package up all of your security tables and deploy them to your production environment. There is a wizard that will create the deployment data packages for you and then deploy them to your production environment. This also provides you with a distribution mechanism. Even if you are writing an internal application, you will still want to work this way. If you don't want to use the DDT, then you will want to do what the DDT does for you and extract them from the Security tables in the StrataFrame database and import them into your production database. Using the DDT does this for you in seconds though, so it is really the route you will want to take.
|
By Jeff Pagley - 10/7/2010
I have not deployed the production database yet. I am still working on the developing the database. However, I have not used the DDT. So what you are saying is once I develop my production database then I can add the security tables and their records from the Strataframe database to my production database using the DDT, correct? What if I have two or more projects in the RBS Editor system for different development applications I am working on. Will the DDT enable me to deploy the security tables and only the records associated with the security project which is setup for the application I am deploying?
Jeff
|
By Trent L. Taylor - 10/7/2010
Working backwards, if you have two projects then you need to create 2 security projects. Once for each, so if you set this up correctly, then yes, you can distinguish between each project and deploy them appropriately. When you create the permissions, then you just pop over to the DDT, repackage, then deploy data only (after the tables have been created) to update your database with the appropriate permissions.
|
By Jeff Pagley - 10/7/2010
Hi Trent,
I just realize why I wanted the security tables local to my development database. I wanted to use the user PKs from the security user table for other tables like user departments, user schedules and etc. What do you suggest?
Jeff
|
By Trent L. Taylor - 10/7/2010
We do the same thing, we store the user PK on every record created on every table in our entire system.
MicroFour.StrataFrame.Security.SecurityBasics.CurrentUser.UserPk
Going for memory on the above code, but that will give you the currently logged in user. You will then use the BO's SetDefaultvalues event to set the user PK on your records when a new row is created. This then becomes an automated process in your application.
|
By Jeff Pagley - 10/7/2010
Yep. I knew that. I guess I should have been more specific. Let's say I want to create a View to query the users and departments information or any view for that matter which needs to return the user name. The SFUsers table resides in the Strataframe database. When I go to deploy the database and move all of the security tables to the production database, all of the views associated with the SFUsers table located in the Strataframe databse will be broken. What does everyone do in this case when moving from development to production?
Also, in regards to deployment of security, the administrator will be adding new users and roles to the production database which will not be in my development database. In this case, I only want to update the permissions data in their production database. Will the DDT enable me to do that?
|
By Trent L. Taylor - 10/7/2010
The administrator can add as many users and roles as he would like, just not permissions. The system, by default, allows users to be created at run-time as well as roles. So that won't be an issue. As for your view, why would it break? I don't understand how deploying data would break your view. Are you hard-coding primary keys, user names, etc? If not, then your view would not change whether it is being maintained in your production environment or whether you are deploying through the DDT. Structures aren't changing, just the contents of the tables. So I don't guess I understand your point here....I could just be misunderstanding what you are trying to accomplish with your view also. You may need to elaborate some more.
|
By Jeff Pagley - 10/7/2010
Sorry about the confusion. Let me explain it this way. This is only during development. My UsersDepartments table is in my current development database called "CEI". The SFSUsers table is in the Strataframe Database. I want to combine the two tables into a single View in my CEI development database. Therefore, within my development database I would have to create a View which includes this SQL statement:
SELECT us_pk AS UserID, us_Username AS UserName, us_FirstName + N' ' + us_LastName AS FullName
FROM StrataFrame.dbo.SFSUsers
As you can see I specifically have to refer to the StrataFrame database in the SQL. Now I am using this view in my application. When I deploy my development database to a production database and deploy the SFSUsers table to production database, I will not be able to point to Strataframe.dbo.SFSUsers in the saved View, because the SFSUsers table will now be local to my production database. When the application runs the View or any view using this SQL, they will fail. I would have to alter all of the Views to drop the "Strataframe" before deploying them. Maybe I am confused, but this is what I am seeing is my issue. What don't I understand?
Thanks,
Jeff
|
By Trent L. Taylor - 10/7/2010
Okay...there is the problem. The StrataFrame RBS tables get deployed in YOUR database, not the StrataFrame database. There is a help topic that gives you the scripts to create these tables or you can use the DDT and it will import the structures (and the Deployment Data with your permissions, etc.) into YOUR database. The StrataFrame database should never be used as part of an actual production setting or views like this.
Backing up, if you were to go into the DDT, you would see that if you create your own database that you would use for distribution, there is a link to import the structures of the RBS tables into your database profile. Then, when you deploy your database, the SF tables that are used for security are actually in your database. Next, you want to populate those deployed tables with data from your development environment. That is why you would want to use the DDT Data Deployment Wizard to pick the appropriate RBS development project, then when you build the DDT profile it will bring in the appropriate records. Then when you deploy that package, your deployed database of your database, not StrataFrame, houses the actual security records. It is an export and distribution process that is handled for you by the DDT.
We have a number of queries in our medical application that directly reference those tables as our DB name can change from install to install, but this is never a concern because the SF RBS security tables are in our medical database, not the StrataFrame database.
Hope this clears things up. 
|
By Edhy Rijo - 10/7/2010
Hi Jeff,
Yes you are right to be confused, I have been there too before 
This is what you have to do:
- Using the Role Based Security, create all the users, permissions and groups you will be using in your application. This would be like a template which then will be copied or deployed (with DDT) to the final database.
- Start using the DDT, it will help you a lot in this case and many others, it is really a must have tool.
- With the DDT create a new Deployment Data using the wizard to deploy the "Role Based Security Data" to your own database or if you prefer a separate database. In my case I have it in the application's database.
- Once this is done, then you can create your view using the real tables and everything will be ok.
After all your testing are done and everything is fine, you can always use the DDT to re-deploy new permissions to your test database, and then the final production database as you wish. There are a lot of messages in the forum about how this is done so do a search and be ready to dig deeper into this since once you understand it, it will be much more easier and as many things in SF you will be very happy to see the logic behind those features.
P.S.
After using the Wizard to deploy your security tables, pay attention to the "Merge Type" used for each deployment, since that behavior is very important to know what to expect every time you deploy your data, the help file also have more detail information about this as well as messages in the forum.
|
By Greg McGuffey - 10/7/2010
Jeff,
I've been catching up on this and this statement makes me a bit uneasy.
My UsersDepartments table is in my current development database called "CEI". The SFSUsers table is in the Strataframe Database.
The StrataFrame database holds meta data used to define BOs, define localization and to define security data. This is used at design time. The meta data in the StrataFrame database must some how get deployed for use. In the case of BOs, you have to build the partial designer file, which gets put into your VS project. In the case of localization you either export the XML files to be deployed with the app or embedded into the app or you must deploy them to a SQL server. In the case of the security data, it must be deployed to a SQL Server database. None of the data in the StrataFrame database is usable at runtime. It is used to simplify the development of the app. And just like the app, you have to deploy it to use it.
If that makes sense, then you need to somehow deploy the information within the StrataFrame database to a runtime app/security database. You have a couple of options here:
- You can integrate the security tables within you main app database. This is easy if you are using DDT to manage that database as you can easily import the security tables/views into the database in DDT.
- You can use a separate database for security. You might want to do this if several apps all share the same security or if you can't use DDT to manage the main app (perhaps you don't have control over that database).
In either case you must some how deploy the data from the StrataFrame database before you can use it.
Here's the basic process:
1. Add security tables and views to application database. Three ways to do this:
a) If using the DDT for main database, you can just import the security tables.
b) If you aren't using the DDT, but still want the security tables in the same database, see help file for information on to manually add the security tables/views.
c) If you aren't using the DDT and can use a separate security db, then use DDT to setup the security database, importing the security tables/views.
2. Configure permissions, default/required roles etc using Security Dialog from within VS. This stores that information in the StrataFrame database, so it is not yet in the actual database and is unusable at run time. It is usable at design time though.
3. Before testing the app with the new permissions, you need to deploy the data in the StrataFrame database to the runtime database. DDT makes this easy (via deploying a data package), but you can do manually too via T-SQL.
Before we talk about this any more, does this make sense?
|
By Greg McGuffey - 10/7/2010
Jeesh, Trent and Edhy beat me to it! Hopefully between the three explanations you're starting to get less confused (and not more confused!).
|
By Jeff Pagley - 10/7/2010
Hi Edhy, Trent and Greg,
As always, thank you for the awesome support and for all of the information. Sorry, I really do not want you guys to spend some much time explaining the RBS deployment scenario. But as a result, I do understand what is needed. My confusion was I don't know yet what all of the permissions or groups I need, because I am just starting to look at RBS for the application. Currently, I am at the mercy of the company users and management and things like Security during development can change often. I was hoping there was a way to keep everything in Strataframe while I was creating the RBS system. At this point, I see I will have to dive into DDT to deploy my security data as it changes. To be honest, it is just one more thing I did not want to have to tackle at the moment.
Thanks,
Jeff
|
By Greg McGuffey - 10/7/2010
If your using the DDT, the actual deployment takes about a minute. It'll take a bit to figure it out, but once you dive in, we're here to help with the issue that come up. Start with the help file, search the forum (there are lots of info about this...I think Edhy and I both asked about this when we were staring out).
|
By Trent L. Taylor - 10/7/2010
Well, if it is that fluid at the moment, just write an SQL script to extract the contents from the RBS tables in the StrataFrame database and dump them into your database. It is the same thing, really. That way you can just continue to add your permissions, etc. and then go run your script to move those permissions into your DB. Just make sure that you have the RBS tables in your database, then write a script that extracts from StrataFrame and dumps into your database. By doing this you don't have to tackle the DDT (which would probably be faster, BTW  ).
|
|