Added support for user profile installed apps 🥳 #176
Conversation
|
@KnifMelti something close to what I was thinking |
|
Then #Set ACL for users on logfile means you're writing user logs to the main log file too? |
|
Yes, to avoid to have several places to troubleshoot. But can be changed, it's still a draft :) |
|
No need to change, I've changed my shortcut handling already... |
|
Ok, now it seems to work pretty well :) |
|
If running in user context, shouldn't the black/white list check be inactivated? |
|
it depends what you have in the white/black list. If you want to block certain apps to update, it doesn't care if you are user or system, no ? Same for white list I guess. |
|
Yes it is important if it's running as system, but not as user. If the block is because the version must be a certain one or because you've noticed that it's always fails when upgrading , you're right... |
|
yes i agree. but most of apps should be installed for system. It is just for apps installable only in user context. if I understand well, you whitelist apps for system, but full open for user ? |
|
Yes, that's the scenario we think is needed. |
|
because in some cases, my customers want only support whitelist, whatever it is system or user context. They want to avoid to manage side effects |
|
Yes, I understand the total lockdown - support wise - but it's a constant balancing between user experience and security/support. |
|
with something like |
|
The thing is, if you use white list, it means you want to control the apps you want to update. So it doesn't really make sense to have White list for system app and blacklist (with 0 black listed apps in fact) for user. See what I mean ? |
|
Control the apps installed in System context, yes. |
|
yes, i'm working on it :) but under white list, it's easy to say Whitelist for system, nothing for user. But I don't want to handle cross listing ^^ like Whitelist for system and Black list for user... etc |
|
and for blacklist, it's easy. If |
|
Ah, I see the problem now with Whitelist! |
|
made few changes |
|
Ah, nice trick! |
|
Anyway, if |
|
few more tests and I merge tomorrow |
| Write-Log "User context execution not installed" | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
I think here we should remove the winget_system_apps.txt file after user context run. Because if someone uses WAU at home as user with admin right, you can run WAU with your user account and manage all in one. You don't really need the system part (this is mainly for companies where users need system execution to install udates). What do you think @KnifMelti ?
There was a problem hiding this comment.
In fact, it needs to be determined during install script. If WAU is installed by system (via Intune, SCCM, GPO,...) then, we need to have WAU as it is now. But if WAU is installed by an admin user, then it could run all in one. Sort of optimization ^^
I will think about that for the v1.16.0
There was a problem hiding this comment.
Then make it a choice...
...because a lot of the home admins also have families with no admin rights and they're using the same family computer!
There was a problem hiding this comment.
ok, I had other possibilities in mind (to run different way regarding system, admin user and standard user), but we'll leave it like that for now 😅
Closes #167
Closes #68