Whoo, long thread .  I'll read it in detail when I get a few free minutes, but just to throw a quick clarification out there, Greg is correct that we don't get heavy handed with the permission deploy since there are quite a few questions as to why the two (DDT definitions and actual records in the database) don't line up.  In short, we leave this up to the developer to decide how he wants to handle it.

In our medical app, we choose to wipe out the permissions via a post-deployment script before deploying them in the DDT to prevent the issues Edhy has mentioned. Our Post-Deployment script looks like this:

This may be something we examine deeper in the future, but as it stands it's fairly straight forward to handle the different scenarios with the available merge types and/or a deployment script. As such we don't want to make any hasty changes that could break the deployments of existing developers

Hi Dustin,



Glad to see you back



In deed, what I am looking for is for how SF developers are dealing with these realities. To make story short I am releasing an application and once customers start buying I will not have remote access to some of them after installation and I need to automate the data update process as much as possible without user intervention.



Thanks for the script, I will test it right away, and when you have couple of minutes free, I would appreciate if you can read the whole thread.

Edhy Rijo

Hey Dustin,



One quick clarification if I may ask...



If your Post Script is always resetting the Permissions records then I should assume that the StartDataDeploymentPhase() should always be run to ensure the Deployment Data packages are always deployed not matter what the Deployment Options (Standard, SP-Views-UDF Only) is used, right? Of course this would include all Data Deployment packages defined in the DDT, not only RBS.



Again, in my case all the update is done automatically, so I want to put together all the pieces to make sure this will work.



Thanks!

Edhy Rijo

Sorry, this thread keeps getting bigger, but here is another request...



While testing Dustin suggestion, I noticed that the Pre/Post Deploy Script will only run for the Deployment Options of Standard and SP-Views-UDFs Only, when deploy using "Deploy Data Only" the Pre/Post will not run.



Can anybody confirm this? and if that is the case, I guess we may need 2 more hooks Pre/Post Deploy Data Scripts so we can have the hooks needed to deal with this.



Keep in mind that in my case since the DDT does not handle INCLUDE indexes (see post), I have to use a Post-Deploy Script to create those indexes in a table with millions of records which takes from 5 to 25 minutes to complete with each update, by me controlling the process to of how the deployment will be done, I can save customers time, waiting for the update to rebuild those INCLUDE indexes when changes will not affect those big tables using a deployment other than "Standard".

Edhy Rijo

Yep, using the post deployment script I posted earlier would obligate you to deploy the permissions every time, otherwise you'll end up with customers that have empty permission tables.

As far as adding additional hooks to DDT deployment options, I'll talk to Trent and see if we can add it to the enhancement list. Since workarounds exist here (handling the table clear outside of the DDT, doing full/stored procedure deployment so that the scripts get fired, etc.) this isn't mission-critical, so it may not make it in until the next time we are going through the DDT.

Thanks for the explanation Dustin. Even though this may not look as mission-critical, the whole idea is to use the DDT to take care of this kind of things instead of having many stored procedures all over. Hooks can be added to allow us to control this kind of situation. I hope you guys can take the time to review this and other DDT enhancement request to make the DDT more powerful and flexible for us .

In the mean time as suggested, I will create a SP to try to handle this gracefully for the end user.

Edhy Rijo

Edhy,

You may want to take a look at the 1.7.3 version. We added a few hooks and whistles to the data deployment options that could make some of the above work more smoothly for you .

Hi Dustin,



Thanks for the information. I am already looking at those to incorporate then in my automatic logic, will post results later today or tomorrow morning after testing those.

Edhy Rijo

Long, but GOOD thread!

So as Edhy stated, you can end up with orphaned settings. Just today I found I could not access a business object due to the permission key value on the BO having been deprecated in SF security a while back. Question: What is the quickest way to find all of these situations (i.e., without going object-by-object to inspect the assigned permission key).

TIA

________________
_____/ Regards,
____/ al

Hi Alex.

If you knew the keys, you could do a "find" on the solution on those keys and check where they were used, but I guess this is not the case, right?

Maybe doing the same to find the "SecurityKey" string would probably take you to most places where you have set one.