Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement - Export or show list of settings before running #50

Open
cjerrington opened this issue Dec 31, 2020 · 10 comments
Open

Enhancement - Export or show list of settings before running #50

cjerrington opened this issue Dec 31, 2020 · 10 comments
Labels
enhancement New feature or request

Comments

@cjerrington
Copy link
Contributor

Since there are a lot of items to choose from, what would it take to make the selection for the "standard, strict, all" methods and show the items checked in a list? The cards are nice but still a lot to look through. Could this also be listed in the batch file we download to show the list of changes then pause for confirmation?

@undergroundwires
Copy link
Owner

Thanks for the feedback, also for being constructive. I totally agree. I understand that customizing / double checking recommended scripts is not easy and requires a lot of navigation.

A batch script that would prompt for everything would probably be not ideal for most users. So it should be handled during script generation process. So I'd vote for your first solution approach. If I'd define it further:

How about if we would add one more option on "Group by" section (top-right) called "Flat" that would flatten out everything as a list of single checkbox items instead of a tree structure. Each script could then be visualized such as:

  • Clear dotnet CLI telemetry (Clear application history | Privacy cleanup).
  • Clear java cache (Clear application history | Privacy cleanup)
  • ...

It would allow one to scroll down through the list and double check the selected one while also selecting interesting ones spontaneously. But it would be a pretty long list btw as we have around 500 scripts today and it keeps increasing, so we would need to add a scrollbar onto the view.

How does it sound?

@cjerrington
Copy link
Contributor Author

I like that idea as well. You could still have headers for the sections but maybe see them in an ul format tree. This list could also only show the items the user selects or have a toggle between chosen and not chosen items.

I wasn't thinking about a confirmation before each task - that would be a lot. However, it might be good to remind users to ensure they have a backup of their data and even system restore. This process could even be automated with powershell to enable it and then create a restore point. This only works on Windows Desktop OS as Windows Server OS's do not have the same "restore point" feature. I wasn't thinking about a confirmation before each task - that would be a lot.

Something like:

You are about to run a series of scripts that make changes to your operating system.
Please ensure you have a backup of your data and system before proceeding.
Some of the options generated from this script can be reverted but not all.
Please proceed once ready...

The simple pause command will add the "Press any key to continue..."

@undergroundwires undergroundwires added the enhancement New feature or request label Jan 3, 2021
@undergroundwires
Copy link
Owner

Good addition. A button on that view that should say "filter by selected | not selected" would be nice on flat mode. Thanks for clarifying a nice user flow and your feedback 👍🏿

Regarding batch confirmation, sorry for misunderstanding. You're right, it's nice and would also protect from running the file by mistake. If more people in the community think batch step is necessary just let me now to give it a high priority.

@cjerrington
Copy link
Contributor Author

Let me know and I can easily write up the commands for the pause/confirmation at the beginning and enabling the restore point.

@undergroundwires
Copy link
Owner

Hi. It sounds awesome with some help.

To summarize what's been discussed:

  1. Creating system restore point
  2. UX to support a flattened view
  3. Prompting "Are you sure" with script list

I like all of them but I'd suggest against not sending any PR before multi OS support #40 is done. I heavily refactor the application at this moment (biggest since it's been released) with many changes. After the issue closed we could start looking at the PRs. However it could be nice to start building the scripts for 2 and 3 to use in PR later on.

I see a few challenges:

  1. How would we prompt the user? I think a dialog box would be much nicer than dumping a big text on console. However it would be too long, a scroll box would be required. Could we build such dialog box using batch/PS and maybe VBScript? Would VBScript be supported by all versions of Windows 10 without causing us any issues? How do you think we could approach it in a nicest way we can?

  2. Both for prompting user and creating restore point I'd like to make it optional. I run the script as a scheduled job and I know many who do that. It would be bad to prompt them each time or create a system restore point for those who don't want it. We could add them as any other script but they need to run in order: 1. Prompt (if selected) 2. Create restore point (if selected). How could we support some kind of ordering with our current yaml file solution? I think the application would benefit the ordering system for other reasons in future.

I'll also think about questions I stated here and would like to hear if you have any suggestions.

I just want to thanks again for being active in this project with your contributions.

@cjerrington
Copy link
Contributor Author

I do see your position about the prompting. Especially if someone is selecting and downloading the generated script then I do see where they kinda already know what they're doing and selecting. Also running as a scheduled task or periodically I can see as well that prompting would be an issue. Since this is a single batch file we start to limit ourselves on where to start

We could create a variable at the top set promptToRun=true and then later if promptToRun then goto Disclaimer Disclaimer would have the warning message and the pause command before continuing. If we then changed promptToRun=False (or really anything else) then it would be run bypassing the prompt.

Personally I do not like VBS and its not as reliable moving forward. I have used the .NET classes to show the MessageBox window in other PowerShell scripts I've used. Below is a basic prompt that we could wrap into a PowerShell function for reusability in other parts if needed later on.

I do like the fact that it generates a single batch file and doesn't need a config file as well. I dont want this to get that complicated either.

Add-Type -AssemblyName PresentationCore,PresentationFramework

$msgBody = "This is the message body of the window"
$msgTitle = "Message Title"
$msgButton = 'YesNo'
$msgImage = 'Question'
$Result = [System.Windows.MessageBox]::Show($msgBody,$msgTitle,$msgButton,$msgImage)

if ($Result -eq "Yes"){
    # Do the stuff
    Start-Process Notepad
}

We could have a similar set restorepoint=False variable at the top and then if its True goto the RestorePoint and proceed.

I'd be willing to look into these items with you too. Just let me know when the major refactoring is done and I can start studying what needs to be done. I think the restore point is a Windows thing and on MacOS and Linux variants we might just want to specify to have a good system/file backup.

@undergroundwires
Copy link
Owner

undergroundwires commented Jan 19, 2021

Thank you a lot for your feedback. I agree with your arguments so we should skip VBS, let's not use it. The PoC looks great. Happy to be receiving contributions from you 🙏🏿

I'm done with most refactorings so feel free to dive deeper into this 😀 It'd be much quicker if you'd take the lead and I can guide you when it's needed. I think a good place to start with is the checking how the windows.yaml looks like and its documentation.

I see that doing PowerShell contributions is not so smooth today. I created #53 so we can write PS as it is without thinking about inlining and escaping them.

Ordering

The flag solution sounds actually nice for this specific case. It's a good workaround for this single case but I think we should focus on scalability as well. I've been thinking about this as well and will share a potential solution for your feedback:

So in collection files we can introduce a new property called something like order that'd work similarly to z-index or order in CSS. Scripts would look like:

category: Advanced settings
children:
  -
    name: Creating system restore point
    order: -10
    code: ...
  -
    name:  "Are you sure" prompt
    order: -20
    code: ...

All scripts will have order 0 as default and if we want to move something to top we'll input a negative integer like -1 or -10. This way we could also add a positive number to run something at the end of the other scripts. We'll just add a sorting line in UserScriptGenerator.ts based on that property. We can then set something like -10 to system restore script and -20 to prompt for double check. Those who don't want them (like me) can go to "Advanced settings" and disable those two scripts.

We could add both scripts under the category advanced scripts.

Then they would be both selectable and in order. How does it sound?

Sending name of scripts

Another problem that we need to solve is to sending list of script names to the PowerShell script. A solution that comes to my mind is introducing support for parameter substitions in scripts (not its only for subscription) and then we can allow for global substations. Like if any script uses {{ $scriptNames }} inside it would be replaced by the list of the scripts.

We can probably start with system restore script and ordering. Next should be the double check prompt as it would require knowledge of list of scripts in the file that will require more to implement.

@cjerrington
Copy link
Contributor Author

Is there a parameter or data object that already holds the checked values? I think that might help the list idea. Trying to review the code and understand the logic before getting to in-depth.

@undergroundwires
Copy link
Owner

undergroundwires commented Jan 31, 2021

Yes there's ApplicationContext.ts singleton that holds CategoryCollectionState.ts per each OS. The whole state is saved there for each OS, including UserSelection.ts that you're looking for. Vue components consume the state by extending StatefulVue.ts. It reveals getCurrentContextAsync to get current state and abstract handleCollectionState that's updated each time OS is changed.

You can start by looking at TheCodeArea.vue that listens to code changes and build the code, it's just to F12 deeper from there 😀 The scripts are loaded from collection files and parsed/compiled by ApplicationParser.ts.

I also improved documentation by adding Presentation.md and Application.md to further defined the layering.

Let me know if more documentation is needed then I'll create those, or just any improvements regarding the code base. I try to keep it clean, maintainable and easily contributable as this will be a very long term project. And feel free to ask if anything.

@cjerrington
Copy link
Contributor Author

Thanks! I'll keep taking a look. Working on this during some "off time" from other projects and work.

undergroundwires added a commit that referenced this issue Aug 29, 2021
1. *Grouping* becomes *view*. Because *view* is more clear and extensible than *grouping*. It increases flexibility to extend by e.g. adding *flat* as a new view as discussed in #50, in this case "flat *view*" would make more sense than "flat *grouping*".
2. *None* becomes *tree*. Because *tree* is more descriptive than *none*.

Updates labels on top menu. As labels are updated, the file structure/names are refactored to follow the same concept. `TheScriptsList` is renamed to `TheScriptsView`. Also refactors `ViewChanger` so view types are presented in same way.
undergroundwires added a commit that referenced this issue Dec 18, 2023
This commit enhances application security against potential attacks by
isolating dependencies that access the host system (like file
operations) from the renderer process. It narrows the exposed
functionality to script execution only, adding an extra security layer.

The changes allow secure and scalable API exposure, preparing for future
functionalities such as desktop notifications for script errors (#264),
improved script execution handling (#296), and creating restore points
(#50) in a secure and repeatable way.

Changes include:

- Inject `CodeRunner` into Vue components via dependency injection.
- Move `CodeRunner` to the application layer as an abstraction for
  better domain-driven design alignment.
- Refactor `SystemOperations` and related interfaces, removing the `I`
  prefix.
- Update architecture documentation for clarity.
- Update return types in `NodeSystemOperations` to match the Node APIs.
- Improve `WindowVariablesProvider` integration tests for better error
  context.
- Centralize type checks with common functions like `isArray` and
  `isNumber`.
- Change `CodeRunner` to use `os` parameter, ensuring correct window
  variable injection.
- Streamline API exposure to the renderer process:
  - Automatically bind function contexts to prevent loss of original
    context.
  - Implement a way to create facades (wrapper/proxy objects) for
    increased security.
undergroundwires added a commit that referenced this issue Jan 13, 2024
This commit introduces native operating system file dialogs in the
desktop application replacing the existing web-based dialogs.

It lays the foundation for future enhancements such as:

- Providing error messages when saving or executing files, addressing
  #264.
- Creating system restore points, addressing #50.

Documentation updates:

- Update `desktop-vs-web-features.md` with added functionality.
- Update `README.md` with security feature highlights.
- Update home page documentation to emphasize security features.

Other supporting changes include:

- Integrate IPC communication channels for secure Electron dialog API
  interactions.
- Refactor `IpcRegistration` for more type-safety and simplicity.
- Introduce a Vue hook to encapsulate dialog functionality.
- Improve errors during IPC registration for easier troubleshooting.
- Move `ClientLoggerFactory` for consistency in hooks organization and
  remove `LoggerFactory` interface for simplicity.
- Add tests for the save file dialog in the browser context.
- Add `Blob` polyfill in tests to compensate for the missing
  `blob.text()` function in `jsdom` (see jsdom/jsdom#2555).

Improve environment detection logic:

- Treat test environment as browser environments to correctly activate
  features based on the environment. This resolves issues where the
  environment is misidentified as desktop, but Electron preloader APIs
  are missing.
- Rename `isDesktop` environment identification variable to
  `isRunningAsDesktopApplication` for better clarity and to avoid
  confusion with desktop environments in web/browser/test environments.
- Simplify `BrowserRuntimeEnvironment` to consistently detect
  non-desktop application environments.
- Improve environment detection for Electron main process
  (electron/electron#2288).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants