Not implemented administrator mode

[GasDauMin]

In some cases would be nice to have "run as admin" option, it is relevant for terminals and consoles.

[end2endzone]

Yes that is a good idea but I do not know if I understand what you mean. Sure the <exec> action does not support launching another application or batch file as administrator. We could all a new xml attribute (for instance admin="true" or level="admin") to the <exec> element.

I did not think of that because I never had such a use case. A "run as admin" is already available by default in Windows 7 context menu when you right click a .exe or .bat file:

Is this feature missing in Windows 10?

Could you elaborate a little more on your idea?

[end2endzone]

Again, could you elaborate a little more on your idea?

[GasDauMin]

Yes of course.

Idea is realy simple I talking about running some of context menu items with administrator permissions.

Example:

We need to change file content and ordinary user has no rights to do so, because of this configuration.

For that purpose we need to run editor as administrator and only then will we be able to change the contents of the file and save it.

Example how to do it in registry is there:
https://winaero.com/blog/powershell-administrator-context-menu-windows-10/

Example how to do it in C++ language in Windows Shell interface:
Please focus on the verb runas and its purpose
https://docs.microsoft.com/en-us/windows/win32/shell/launch

[end2endzone]

Thank you for the clarification. I do understand what you mean.

Looking at the ShellExecute() example, I see "run the application elevated or enter the credentials of an administrator account used to run the application". I think for your use case it would be better if we would simply run the process with elevated privileges and not as the "Administrator" user.

Regarding the required changes...

1. We will need a new attribute to the <exec> action. Something like administrator="true", mode="elevated" or elevated="true", a flag to indicate that elevated privileges is required for launching the executable. I only took 2-3 minutes to think of something. Maybe you can find a better attribute name.

2. The current implementation of ActionExecute::Execute() uses ra::process::StartProcessUtf8() which do not support elevated privileges. Also the function ra::process::StartProcessUtf8() uses CreateProcess() and not ShellExecute() for creating processes. The code would have to be changed to look like ActionOpen::Execute() which uses ShellExecuteEx(). Do not forget to use the unicode version (ShellExecuteExW()) and not the ansi version.

3. While migrating from CreateProcess() to ShellExecuteEx(), we could also create a new attribute to the <exec> action called window which would take the values normal (by default), minimized and maximized and link this attribute to the nShow field of the SHELLEXECUTEINFOW structure. This would allow launching processes in a maximized window. I don't have a specific user case in mind (my notepad.exe always open in normal mode). If you feel that this change would need to be moved to a new issue, feel free to do so.

4. The administrator="true" attribute (or whatever other name it may have) that allow administrative privilege on the <exec> action could also be applied to the <open> action. Instead of having to specify <exec path="C:\Program Files (x86)\Notepad++\notepad++.exe" arguments="${selection.path}" elevated="true" />, we could also do <open path="${selection.path}" elevated="true" /> which would open the default application associated with the file extension of the selected app in elevated privileges mode.

What you do think of these ideas ?

Would you like to work on this issue ? I can assign it to you if you are interested. I would gladly accept your contribution.

[GasDauMin]

The most common and understandable attribute would be **administrator**. And for migration, it would be useful for my head. Of course, we can always keep the possibility of previous functionality. It would be difficult to start working on that right now, especially since the change is not part of ShellAnything but part of RapidAssist. I don’t really know how I should successfully modify these two parts at the same time and share the changes later.

[end2endzone]

We will go with administrator attribute.

I think I misspoke. When I read about my previous comment at bullet 2, I understand the confusion. Let me rephrase that. The code from RapidAssist cannot be copied to ShellAnything because it uses CreateProcess(). I also do not plan to change the implementation of ra::process::StartProcessUtf8() to use ShellExecuteEx() because RapidAssist is a multi-platform library and I don't know if I could change the function signature to something like ra::process::StartProcessUtf8(..., bool administrator) and still support all platforms. For these reasons, I think it would be best to change the implementation of ActionExecute::Execute() to uses ShellExecuteExW(). In other words, we should do the same as with ActionOpen::Execute() which code do not depends on another library.

I appreciate all the help I can get to work on this project. I am still open for this contribution of yours. I do understand that European holidays can last many weeks and I see no problem waiting for your availability. I would be glad to have another contributor on the project. Knowing that you only need to modify ActionExecute::Execute() and ActionOpen::Execute() (and not RapidAssist), I believe that you would be able to implement it without too much compilation.

If not, then there is no problem and I will make the required changes myself. Just keep me informed on your intentions so I can plan release versions and update issues accordingly.

Thank you.

[GasDauMin]

It will be an easy task and a great opportunity to practice working in a team, I take this job :-)

[end2endzone]

Will you also have the time to complete this task before October 4th?

[GasDauMin]

Yes, I have time, I will try to do this task as well.

[GasDauMin]

FYI. As I mentioned earlier, it was time to work on this task, but deadlines also put pressure on the main job. At the moment I have a separate branch in the local git and I am doing task on it. Becouse task not finished yet and in free time I'm still workin on it, I see no point in pushing intermediate changes.

[end2endzone]

Don't worry. There is no problem at all. Feel free to use all the time you need in order to complete the task properly. Nothing good will come out of this if you are rushing yourself. I sometimes also have other priorities and family obligations.

…

On Sun., Oct. 4, 2020, 15:53 Mindaugas ***@***.***> wrote: FYI. As I mentioned earlier, it was time to work on this task, but deadlines also put pressure on the main job. At the moment I have a separate branch in the local git and I am doing task on it. Becouse task not finished yet and in free time I'm still workin on it, I see no point in pushing intermediate changes. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#56 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHSIHBLAGBKBJTAGWFVQ6Z3SJDHDPANCNFSM4OP5KHPQ> .

[GasDauMin]

Hi, this time I commited changes to a separate branch feature-issue56, and now I want to tell you about the problem-solving options I have chosen. I just added a new verb attribute to the <exec> tag element. In this case verb="runas" doing what I expected. I did several tests and admin mode worked for me. I tried not to ruin anything but I still think your review is needed.