Open Sargastic opened 4 months ago
This is probably because the plugin uses the settings to store the jobs that the server side loops through for starting. If the operator doesn't have the ability to save settings then even though it shows on the tab it might not be getting saved to config.yaml like it does for admin users. Changing this logic would require a good amount of reprogramming and not sure when I would get around to implementing.
I thought it could be something like that when I saw the jobs were saved into the config.yaml file. If solving this issue, which seems like an edge case, requires an inordinate amount of your time, it's not worth it. I can live without my operator-personna being able to schedule jobs.
It's not a huge amount of work to replace the settings method with a plugin API and separate storage of this data. I'll leave this open for the future when I have some spare time to program. Along with those changes I would implement it's own set of plugin permissions that would allow you to set them for the operators group.
I just installed the plugin, no errors whatsoeverx
The print scheduling seems to works only for members of the « admin » group.
If a user from another group (namely, the « operator » group, which can start and stop prints) schedules a job, the job is displayed in the scheduler tab but nothing happens. Debug log shows « Looping through scheduled jobs » but not job is triggered.
Clock is properly synced.