Feature Request: Password lock slicing profiles

[curieos]

This is the scenario. I am the "printer curator" for X organization. I have spent many hours ensuring the slicing profiles for my org's printer are reliable and will produce good g-code for most all prints. These profiles are available for many materials and layer heights already so any newcomer, regardless of skill level, can simply load an stl into slic3r, select the correct settings from the drop down menus, and then export the gcode for printing.

I (and the governing body of the organization) do not want these settings to be changed without my knowledge. I let other people know "use these settings, don't mess with them", and additionally I setup a backup to automatically restore the settings. Despite this policy (and measures to minimize their effects), a few people modify the settings anyway. Most of the changes go off fine, but one expeditious newcomer to 3D printing decides to touch something that they shouldn't and now the printer has broken.

I think it would be useful to have an optional password to lock the slicing profiles to prevent this scenario from happening (I know this has happened at the makerspace I used to go to at least a few times now, and its enough to make them consider purchasing an S3D license which has such locking feature).

Someone brought up modifying simple settings like support generation, infill percentage, etc. This is a good point, and I think that the setting overrides should be exempt from this password lock.

[lordofhyphens]

I don't think this is something that is in scope for Slic3r; it is almost always better to use a better solution (SVN with needs-lock comes to mind) than to try to implement a minimal security system.

I keep my own Slic3r configuration under version control (git, but that's because it meets my needs).

[curieos]

An example, the makerspace I used to be apart of is having a problem with this. I'm not sure if they are using Slic3r or KISSlicer, but they have the tuned profiles backed up and every time the computer is turned on or the slicer is quit these profiles are restored. This does not prevent a user from tweaking the profiles while the slicer is running AFAIK, since this data is kept in memory and the config file is only read when switching between profiles. This is the problem that I see and I dont know any other way to fix it.

[bmx666]

It's remind me some feature from customer:

1. At the beginning: I wanna lock settings by some key or password
2. After few days: I wanna lock all settings, but some of them available for modify without request access
3. After few weeks: I wanna manage control. Lock some parts of settings by roles, groups and audit every options and configure them with manage control panel.
4. After month: I wanna delegate some specific options for change by roles or groups.
5. Project was completed. How users using this feature now? Company create one master role and group, then delegate everybody all rights.

P.S. Useful feature for very big corps.

[xoan]

@bmx666 lol :D

I agree this kind of features should be handled by the system itself or by using external tools, such rsync/vcs and permissions.

[curieos]

How does this solution prevent the settings stored in memory from being modified? This is the real problem I'm chasing here. Those external tools may work fine to keep users from modifying the .ini files, but how does that stop them from opening slic3r and messing around?

[bmx666]

@curieos, what about fork this project and hide buttons in gui, for prevent of modify settings? But in console version users can use any settings.

[curieos]

I understand the console can be used to do anything, thats fine. I only care about the UI.

This is a really simple problem with a really simple solution and tbh I think you are over complicating it. If I get time I will try to work on this on my fork.

[7eggert]

What/how is your printing process and how do you intend the password from preventing damage while also allowing the necessary adjustments to the printer settings (brim, support, fan)?

[alranel]

@curieos, the scenario you described makes sense a lot. I have a good idea for solving it (no passwords involved but should still work). As soon as I can, I'll implement a proof of concept.

[NateTG]

What about having some kind of 'profile history' so that it's easy to undo changes instead?

[curieos]

I think some people were misinterpreting the problem so I rewrote my feature request to describe the scenario/problem that I see.