https://bugzilla.novell.com/show_bug.cgi?id=698250 https://bugzilla.novell.com/show_bug.cgi?id=698250#c40 --- Comment #40 from Ludwig Nussel <lnussel@suse.com> 2011-12-07 15:20:01 CET --- (In reply to comment #39)

(In reply to comment #37)

...

It might make sense to have create-device imply create-profile and modify-device, if we change the policy to KEEP. I can patch colord for that if you agree it's the right way forward.

I guess it doesn't make sense to allow creating devices but not to immediately also create color profiles for them so constructing some imply chain one way or another looks useful to me at least.

Actually, this will still be a horrible user experience as you'll still have on popup on each login :/ (the device is re-created on each login)

IOW it is impossible to use colord in a more restrictive setup. The admin can only choose between allowing users to manage color profiles/devices or annoy them. So what's wrong here? Some thoughts. - maybe colord should create permanent entries instead of temporary ones. The amount of different devices you use is most likely not infinite anyways. That way authentication would be only needed once when setting up the device initially. - colord (or rather the front-end that triggers it) could instead of directly throwing an authentication popup at the user just show a passive popup or systray icon to indicate that there are unconfigured devices available. - if temporary devices are a must for some reason maybe colord should use a different privilege or none at all for temporary devices. I have no real problem with setting the privilege to 'yes' at this point if colord runs as it's own user. There's not much it can do besides filling up the hard disk and corrupting it's own database after all (should be easy to jail via apparmor too). Just keep in mind that this will paper over design issues IMO. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.