Yeah, that is another way to find it out!

Hi Ivan.

I was actually hoping that there was a utility or similar that would show assigned permission keys that do not actually exist in the security database, as any such forms, BOs, etc. would definitely not be accessible in these cases. Guess we'll just find those out when users get access denied! lol

Thanks.

________________
_____/ 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.

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 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

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 .

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

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.

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

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