Typically you only setup permissions in the development environment. When you deploy, you always deploy those permissions. So, when you deploy via DDT, you need to make sure you deploy the permission data with it. The trick is to setup the deployment so that it leaves existing data alone and only adds new permissions or updates existing permissions. When you setup a data deployment package, on the data tab you can setup what gets extracted and how it gets loaded into the target database.



It should include the correct project ID in the "Select * From SFPermissions Where" textbox. Note that the project ID is only used with the StrataFrame database at design time. This criterion is used to identify what data needs to be extracted from that database (StrataFrame) to be available to be loaded into the target database. Note you could add additional criteria here if needed.



The Merge Type is were you define what to do with the data if the data already exists in the target. For permissions I set it to Overwrite. There are four options:



- ignore: if the target database already has a record with the same PK, ignore the deployed data.

- merge: if the target database already has a record with the same PK, add the deployed data with a new PK. The original in the target plus the deployed record both exist.

- overwrite: if the target database already has a record with the same PK, delete the target database's record and add the deployed record with the same PK.

- only deploy if table is empty: no target data, so dump deployed data into table.



With permissions, I want to ensure that what I'm using to develop is what's available, so overwrite will update existing permissions with any changes (maybe a category change or a name change) plus add any new permissions I've added.



I also tend to deploy roles, as I may be deploying some role that was requested, but it is possible that they've added new roles, renamed existing roles. My app doesn't actually care about roles. When deploying roles I use a merge type of ignore. Any changes they've made to existing roles are left intact, but my new roles are added. Note that if they were creating roles, I might have to set it up to do a merge and then only select my new roles.



I'd use only deploy if table is empty for bootstrap data, like loading an initial user, so they can initially login (assuming the default admin user wasn't desired).



I hope that helps. If not, keep asking!

I have deployed the RBS to one of my customer and everything is good. Now I am creating more forms and new Permissions and want to update customer with those new permissions and the DDT cannot find the correct permission records at the customer database to be updated.



The problem is that the pm_pk field value at the customer does not match with the pm_pk field value in my StrataFrame database. I believe what happened was that at some point during test, the customer database was TRUNCATEd and then new pm_pk values where auto-generated when security was deployed causing the customer and mine security databases to be out of synch.



So my question is: what is the DDT deployment is using to properly identify the record and do its merge?

In this particular case, for the SFPermissions table, the pm_Key should be the primary field or at least the key field used by the DDT to deploy the data and avoid the problem I am having now. If that is not the case, can you please explain the following:

1.- How is the DDT Data Deployment logic works?

2.- How can I fix my current problem without having to have to recreate all my customer's security configurations for each user?



Thanks!

Edhy Rijo