Bug 208000

Summary: solid actions which are not user-editable should be copied to home directory on editing
Product: [Applications] systemsettings Reporter: Janet <bugzilla>
Component: kcm_solid-actionsAssignee: System Settings Bugs <sourtooth+ssbugs>
Status: ASSIGNED ---    
Severity: wishlist CC: bcooksley, justin.zobel
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Janet 2009-09-20 18:20:53 UTC
Version:           1.0 (using 4.3.1 (KDE 4.3.1), Debian packages)
Compiler:          cc
OS:                Linux (i686) release 2.6.31-0.slh.3-sidux-686

All solid device actions seem to be editable in systemsettings. That's fine because this way you can look at what all the actions do. But when you want to change something you're fooled: the changes aren't saved (for the systemwide actions) because the user hasn't the appropriate rights to do so.

A solution would be to work with policykit but I don't think that's a good idea because the edited actions would be overwritten with the next update of the application that provides the action.

The better solution IMHO would be to copy the action to the user's home (~/.kde/share/apps/solid/actions/) upon saving the changes. That way the changes are persistant even when the user updates the application.
Comment 1 Ben Cooksley 2009-12-14 10:01:29 UTC
Only the changes are written to the users home directory at this time, which should be sufficient, since then updated translations, etc. won't take effect.
Comment 2 Ben Cooksley 2010-02-16 10:01:29 UTC
Testing has revealed this bug is valid. Will try to work on it for 4.5
Comment 3 Justin Zobel 2021-03-13 02:17:44 UTC
(In reply to Ben Cooksley from comment #2)
> Testing has revealed this bug is valid. Will try to work on it for 4.5

Ben was this resolved in 4.x or 5.x at all?
Comment 4 Ben Cooksley 2021-03-13 17:48:40 UTC
I think some changes may have been made, but I don't recall entirely whether they worked 100% reliably to resolve this issue (if memory serves, part of it was due to how the Plasma Applet at the time loaded the Solid Device Actions, making overriding system wide ones problematic)