fix: sync LockScreen service with script migration (Atlas-OS/Atlas#1666) - #67
fix: sync LockScreen service with script migration (Atlas-OS/Atlas#1666)#67Stensel8 wants to merge 3 commits into
Conversation
…g missing registry value deletion This fix ensures the toolbox is in sync with: Atlas-OS/Atlas#1666
|
@TheyCreeper, got time for this one? Ty ;) |
| RegistryHelper.SetValue(PERSONALIZATION_KEY_NAME, NO_CHANGING_LOCK_SCREEN_VALUE_NAME, 1, Microsoft.Win32.RegistryValueKind.DWord); | ||
| RegistryHelper.SetValue(ATLAS_STORE_KEY_NAME, STATE_VALUE_NAME, 0); | ||
| RegistryHelper.SetValue(ATLAS_STORE_KEY_NAME, "path", @$"{Environment.GetEnvironmentVariable("windir")}\AtlasDesktop\4. Interface Tweaks\Lock Screen\Hide Lock Screen.cmd"); | ||
| RegistryHelper.SetValue(ATLAS_STORE_KEY_NAME, "path", Path.Combine(LockScreenScriptDir, "Hide Lock Screen.ps1")); |
There was a problem hiding this comment.
Literally invalid. The script is a .cmd, not .ps1
| RegistryHelper.DeleteValue(PERSONALIZATION_KEY_NAME, NO_CHANGING_LOCK_SCREEN_VALUE_NAME); | ||
| RegistryHelper.SetValue(ATLAS_STORE_KEY_NAME, STATE_VALUE_NAME, 1); | ||
| RegistryHelper.SetValue(ATLAS_STORE_KEY_NAME, "path", @$"{Environment.GetEnvironmentVariable("windir")}\AtlasDesktop\4. Interface Tweaks\Lock Screen\Show Lock Screen (default).cmd"); | ||
| RegistryHelper.SetValue(ATLAS_STORE_KEY_NAME, "path", Path.Combine(LockScreenScriptDir, "Show Lock Screen (default).ps1")); |
There was a problem hiding this comment.
Same thing here, its .cmd, not .ps1
|
Correction: new-update has those script as .ps1 for some reason, which I don't believe is intended |
|
See: Atlas-OS/Atlas#1666 As mentioned above. |
That was also part of an earlier PR. In my opinion, we shouldn't use .cmd / BAT anymore for new scripts as it has its limitations. Also, some regkeys and error handling could not be set in a way that the errors would be catched :) Your Atlas Toolbox still misses some newer regkeys / API's that Windows has added in the meantime to managed the LockScreen GPO's. The result is that, the AtlasDesktop scripts work fine now, because they are migrated. This AtlasToolbox doesn't. |
|
I reverted those changes. See d21ecf5 In the cases where we do need error handling, we use a .cmd which calls a .ps1 in AtlasModules. There is no need for error handling in registry editing. We've never had any issues with those and I doubt we'll get any in the future I will probably have some kind of module which checks for admin and does the state switching since that could be useful in powershell, but otherwise we'll continue using .cmd |
|
Fair enough. I understand the need for simplicity. However, PowerShell is far more readable and gives you access to a more modern and more secure way of handling things. CMD is a dead horse that still exists for the legacy and enterprise support. As how they've been deprecating WMIC and VBS, the CMD suite will follow soon.
No, not really. Because a teammate of you once said the following:
The thing is that Microsoft recommends users to gradually migrate to .PS1. Doing super big PR's with huge diffs is not maintainable for reviewers. So, it's not "stupid". But thanks for your opinion. Also, I saw that the path Atlas is going (the na-jack branches), is also more and more PS1 native. When I saw this, I was migrating and transitioning my versions as well, in order to better align with your future versions. We should be prepared for the case if they ever pull the plug out of CMD. Because, they told that PowerShell is the current scripting and automation language. Do not forget that CMD was an invention of the MS-DOS era. Back when the dinosaurs lived ;) Have a great one and keep up the good work on Atlas. |
Old version: #66.
This brings the Toolbox's
LockScreenConfigurationServicein sync with the script migration done in Atlas-OS/Atlas#1666.The Atlas scripts were updated to handle both
NoLockScreenandNoChangingLockScreenregistry values. WithoutNoChangingLockScreenbeing cleared on re-enable, the lock screen settings stayed greyed out in Windows Settings ("managed by your organization") even after toggling the lock screen back on via the Toolbox.Changes:
Enable()now also deletesNoChangingLockScreenalongsideNoLockScreen, which is what kept Settings greyed outDisable()now also setsNoChangingLockScreen = 1to be consistent with what the scripts doDisable()andEnable()now reference the.ps1script paths instead of the deleted.cmdfilesTested locally: toggling off and on via the Toolbox correctly sets and clears both registry values, and the lock screen works as expected after re-enabling.
This fixes: #68
Related: Atlas-OS/Atlas#1664
Related: Atlas-OS/Atlas#1666
Related: #68