Export-DbaUser - Refactor T-SQL User-Role Scripting to Eliminate Dependencies #9232
Conversation
Refactored the T-SQL scripting for user-role assignments to enforce independence between scripts. This change removes the need to track which roles have been scripted, preventing dependency issues when scripts are run out of order. Below is a detailed introduction to the issue and the solution. In this new approach of scripting, we do not maintain a variable to track the roles that have been scripted. Our method involves a consistent verification process for each user against the complete list of roles. This ensures that we dynamically include only the roles to which a user belongs. For example, consider two users: user1 is associated with role1 and role2, while user2 is associated with role1 and role3. Attempting to memorize the scripted roles could result in Transact-SQL (T-SQL) statements such as: ``` IF NOT EXISTS (role1) CREATE ROLE role1 IF NOT EXISTS (role2) CREATE ROLE role2 IF NOT EXISTS (user1) CREATE USER user1 ADD user1 TO role1 ADD user1 TO role2 -- And for another user: IF NOT EXISTS (role3) CREATE ROLE role3 IF NOT EXISTS (user2) CREATE USER user2 ADD user2 TO role1 ADD user2 TO role3 ``` ` However, this script inadvertently introduces a dependency issue. To ensure user2 is properly configured, the script segment for user1 must be executed first due to the shared role1. To circumvent this issue and remove interdependencies, we opt to match each user against all potential roles. Consequently, roles are scripted per user membership, resulting in T-SQL like: ``` IF NOT EXISTS (role1) CREATE ROLE role1 IF NOT EXISTS (role2) CREATE ROLE role2 IF NOT EXISTS (user1) CREATE USER user1 ADD user1 TO role1 ADD user1 TO role2 -- And for another user: IF NOT EXISTS (role1) CREATE ROLE role1 IF NOT EXISTS (role3) CREATE ROLE role3 IF NOT EXISTS (user2) CREATE USER user2 ADD user2 TO role1 ADD user2 TO role3 ``` While this method may produce some redundant code (e.g., checking and creating role1 twice), it guarantees that each portion of the script is self-sufficient and can be executed independently of others. Therefore, users can selectively execute any segment of the script without concern for execution order or dependencies.
|
hum, the single exported file before had issues ? |
The issue with the single exported file including roles not pertinent to the user. The pull request has made two justments:
|
|
okay, then maybe it's good to put a regression test into tests/Export-DbaUser.Tests.ps1 to avoid this "way" getting reverted by a next edit. |
|
I'd agree, this seems to be adding more T-SQL code to something that could be done via PowerShell methods in less code (possibly). A preference for me would also be to put this logic in a |
wsmelton
changed the title
Can we change it like this:
|
|
Thank you all for y our feedback. I will merge once the PR is approved. |
|
Any updates? |
|
I don't have any preference in the matter of "PS vs T-SQL" but I'd add a regr test to make sure this behaviour doesn't get reverted at a later stage. |
|
Thank you -- @0x7FFFFFFFFFFFFFFF is that something you can do? add in a test that would fail if your PR's functionality gets impacted? |
|
Thanks for reviewing the pull request and for the suggestions. I'm pretty busy recently, which has impacted my ability to respond promptly. I appreciate your understanding and patience. Regarding the test for the |
|
we can definitely help, just need to prop up two user with roles exposing the behaviour you want to fix and then make sure everything stays in the same way "forever" ;-) |
|
I've added a test. |
|
Thank you very much! Apologies for the delay. Merging finally 🙏🏼 |
Refactored the T-SQL scripting for user-role assignments to enforce independence between scripts. This change removes the need to track which roles have been scripted, preventing dependency issues when scripts are run out of order. Below is a detailed introduction to the issue and the solution.
In this new approach of scripting, we do not maintain a variable to track the roles that have been scripted. Our method involves a consistent verification process for each user against the complete list of roles. This ensures that we dynamically include only the roles to which a user belongs. For example, consider two users: user1 is associated with role1 and role2, while user2 is associated with role1 and role3.
Attempting to memorize the scripted roles could result in Transact-SQL (T-SQL) statements such as:
`
However, this script inadvertently introduces a dependency issue. To ensure user2 is properly configured, the script segment for user1 must be executed first due to the shared role1. To circumvent this issue and remove interdependencies, we opt to match each user against all potential roles. Consequently, roles are scripted per user membership, resulting in T-SQL like:
While this method may produce some redundant code (e.g., checking and creating role1 twice), it guarantees that each portion of the script is self-sufficient and can be executed independently of others. Therefore, users can selectively execute any segment of the script without concern for execution order or dependencies.
Please read -- recent changes to our repo
On November 10, 2022, we removed some bloat from our repository (for the second and final time). This change requires that all contributors reclone or refork their repo.
PRs from repos that have not been recently reforked or recloned will be closed and @potatoqualitee will cherry-pick your commits and open a new PR with your changes.
Type of Change
.\tests\manual.pester.ps1)Purpose
Approach
Commands to test
Screenshots
Learning