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

At this time is situation is not handled. You are correct that when deployed (via the DDT data package) and using a Merge Type of Overwrite (actually any merge type), any permissions in the application database that aren't in the deployed data package will simply be ignored.



The reason is that currently the DDT really has no way to know why the permission is in the application but not in the deployed package. It could as it is in your case, that the permission was deleted in the SF database but that is not the only case. It could also be that you are simply distributing only new permissions (you can set a filter when creating a package). In this case, we want the permissions to be left alone in the application.



It would be possible to add a switch (a checkbox) that indicated that you are deploying all permissions and would like to clean up any permissions in the application database that aren't in the deployed data, including removing those permissions from existing roles and/or users. However, we'd have to think about this pretty hard. First, I'm not sure this would be a very frequent thing that would happen. Messing with permissions usually involves major changes in the application, as permissions are the link between the RBS and the application, so it likely is pretty infrequent that permissions are deleted, especially from a production app. Second, other than potentially confusing the user, they do no harm being left in. Third, it is certainly possible for the developer to use a post deployment script to clean them up, which would mean that this is a very deliberate act. But the biggest issue is that if the switch was incorrectly used (turned on when it should be off) and the developer was only deploying new/changed permissions, it would royally fubar any deployed applications. I.e. the ramifications of choosing the wrong setting would be really, really bad.



With that said I'll look into this a bit more to see if I'm missing something...

Greg, I agree with you, but as you know while creating an application, a lot of changes can occur, and the fact that the DDT depends on the developer PK value also could cause a mess when choosing the wrong merge type as I did and new PK values where generated. I also understand why the SF team when this route since it does make sense once the whole process is understood, but since the only way to Add/Change/Delete a Permission records is from the developer computer with the SF database, then there should be an option to avoid leaving orphan records which the End User will have access to, and probably assign them incorrectly if the Security Editor allows then to use those orphan records.



Using a Pre/Post script will always work, but the more we can get out the DDT the better, specially if you are a consultant working on new projects all the time

Edhy Rijo