Bug 151669 - No Administrator mode possible
Summary: No Administrator mode possible
Status: RESOLVED FIXED
Alias: None
Product: systemsettings
Classification: Unclassified
Component: general (show other bugs)
Version: 3.96.2
Platform: Compiled Sources Linux
: NOR normal with 1132 votes (vote)
Target Milestone: ---
Assignee: System Settings Bugs
URL:
Keywords:
: 153467 161102 163901 165124 165411 165679 167366 187207 189855 192719 194216 194519 201421 218381 219818 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-11-01 01:46 UTC by Grósz Dániel
Modified: 2012-01-25 17:02 UTC (History)
53 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Grósz Dániel 2007-11-01 01:46:13 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
OS:                Linux

There is no Administrator mode button in Systemsettings in KDE 4.0 beta 4 in modules like Login manager or Date & Time which usually need administrator rights. It was there in earlier versions which makes me think this is a bug.
Comment 1 Pino Toscano 2007-12-05 10:35:43 UTC
*** Bug 153467 has been marked as a duplicate of this bug. ***
Comment 2 Ben Kevan 2007-12-05 17:57:45 UTC
I can confirm this is still the behavior on 3.96.3
Comment 3 David Broome 2008-02-10 07:01:14 UTC
Same behavior for trunk checkout as of 02/9/2008
Comment 4 David Broome 2008-03-01 20:53:48 UTC
This bug is over 3 months old and the status is still new?

Does it need to be reported against a newer KDE source?
Comment 5 Gerald Cox 2008-03-01 21:45:22 UTC
I reported as a bug under Fedora 9:
https://bugzilla.redhat.com/show_bug.cgi?id=434824
Comment 6 Grósz Dániel 2008-03-01 23:29:34 UTC
I still see no possibility to switch to administrator mode in KDE 4.0.1, for example in the login manager module.
Comment 7 David Broome 2008-04-11 05:12:29 UTC
Same issue from most recent svn.

If this is intended behavior, maybe remove the sections from view that a normal user would not have access to.

Also, adding a menu to open system settings as root might be nice (like we have for konqueror.)  I know it is easy to launch it from the command line, but this would make it more accesible to people not smart enough to launch it themselves (especially since when you switch to root user no kde apps open.)
Comment 8 Pino Toscano 2008-04-21 13:06:17 UTC
*** Bug 161102 has been marked as a duplicate of this bug. ***
Comment 9 Nick Shaforostoff 2008-05-29 15:19:57 UTC
"I know it is easy to launch it from the command line" - depends on your system setup. i used alt+f2 on kde3 to run as root, but kde4 doesnt offer this and there is no kdesu
Comment 10 Pino Toscano 2008-06-12 14:29:36 UTC
*** Bug 163901 has been marked as a duplicate of this bug. ***
Comment 11 Enzo 2008-06-15 17:01:21 UTC
This bug is still present in KDE 4.0.5.
There could be a workaround, namely "/usr/lib/kde4/lib/kde4/libexec/kdesu /usr/lib/kde4/bin/systemsettings" but, at least in KUbuntu 8.04 it doesn't work as it locks the application.
I would say it is a major, show stopper bug.
Comment 12 Lars Noodén 2008-06-15 17:24:23 UTC
 I use "sudo" to run "/usr/lib/kde4/bin/systemsettings" from the shell.  But that's a work-around not a fix.  I'd agree that not being able to enter administrator mode for system settings is a show-stopper.
Comment 13 Jan Holthuis 2008-06-25 18:53:10 UTC
Still present in Kubuntu 8.04 KDE 4 Beta 2.
Okay, it's easy to open a terminal and type »sudo /usr/lib/kde4/bin/systemsettings«, but inexpierienced users will go crazy!

Please assign that bug to someone so that it will be fixed soon...
Comment 14 Oswald Buddenhagen 2008-06-27 19:46:23 UTC
*** Bug 165124 has been marked as a duplicate of this bug. ***
Comment 15 Oswald Buddenhagen 2008-06-30 14:16:46 UTC
*** Bug 165411 has been marked as a duplicate of this bug. ***
Comment 16 Pino Toscano 2008-07-04 03:21:45 UTC
*** Bug 165679 has been marked as a duplicate of this bug. ***
Comment 17 Frederik Schwarzer 2008-07-16 07:40:12 UTC
Still valid for KDE 4.1 RC1
Comment 18 Jan Holthuis 2008-07-16 15:22:21 UTC
Apart from the missing proxy support, this is one of the most critical flaws in KDE4. I don't know much about the KDE4 source code, but I expect this should be really easy to fix.

Unfortunately, I'm not a C++ programmer (but I'm learning atm^^) and this bug is really annoying, so can someone PLEASE fix this?
Comment 19 Kevin Kofler 2008-07-16 15:36:46 UTC
There's this hack courtesy of Lukáš Tinkl:
http://cvs.fedoraproject.org/viewcvs/rpms/kdebase-workspace/devel/kdebase-workspace-4.0.72-rootprivs.patch?rev=1.1&view=markup

plus the clock.desktop fix which goes with it:
http://cvs.fedoraproject.org/viewcvs/rpms/kdebase-workspace/devel/kdebase-workspace-4.0.3-timedate-kcm.patch?rev=1.1&view=markup

but we don't expect this hack to be included upstream (that's why we haven't submitted it). Still, I'm mentioning it here in case it helps some people.
Comment 20 Pino Toscano 2008-07-24 18:17:30 UTC
*** Bug 167366 has been marked as a duplicate of this bug. ***
Comment 21 Kamil Neczaj 2008-09-17 11:33:44 UTC
In my opinion the best solution is integrating kde4 with policykit for getting administrator privilages.
Comment 22 Richard Hartmann 2008-09-24 13:53:25 UTC
There is no 4.1.1 for this component, so setting it to 4.1.
Comment 23 Pino Toscano 2008-09-24 14:42:05 UTC
(In reply to comment #22)
> There is no 4.1.1 for this component, so setting it to 4.1.

"Version" means "which version was the bug/wish reported against.
Comment 24 Richard Hartmann 2008-09-24 23:19:41 UTC
I was under the impression that the version should be bumped to the most current version an issue has been confirmed for to prevent bug rot. Sorry.
Comment 25 Anne-Marie Mahfouf 2008-10-08 21:22:19 UTC
Date & Time has now an administrator mode possible. You are prompted for root password for applying the changes. This is trunk, pre 4.2.
Comment 26 Tony White 2008-10-16 22:50:15 UTC
I have found this in 4.1.2 and I don't think it has been disabled deliberately.
Comment 27 Grósz Dániel 2008-10-16 23:08:28 UTC
It is simply not done, not disabled, I fear. I looked at Kubuntu screenshots when I wrote that it was there in earlier versions and I did not know that this is a complete rewrite, not a port of the Kubuntu version.
Comment 28 Dexter Magnific 2008-10-24 11:26:44 UTC
Confirmed for KDE 4.1.2 on Gentoo
Comment 29 Bobby 2008-11-18 11:45:51 UTC
I have noticed that this bug has been reported for almost 1 year now. Will it be fixed for the 4.2 release? That would be great because right now I am forced to use KDM 3 just because of the lack of an administrator mode.
I would like to go all KDE 4 by next release - no patch work ;)
Comment 30 Holly 2008-12-10 21:15:17 UTC
Man, I really hope someone gets to this soon... it's pretty important..
Comment 31 Chad Carew 2008-12-13 01:05:21 UTC
Im using KDE 4.2 betas from Mandriva cooker repo's. Bug still exists. The help says to click the "Modify" button and you will be prompted for a password, but there is no modify button. This is really very irritating, and it doesn't seem like it would be all that difficult for someone to fix this.
Comment 32 Ladislav Nesnera 2008-12-15 13:14:08 UTC
(In reply to comment #31)
I have the same experience with KDE 4.2 betas on openSUSE 11.1. But what can you expect from bugs with "new" status ;?)
Comment 33 Georg Grabler 2009-01-07 10:42:25 UTC
See KDE 4.2 Feature Plan:
http://techbase.kde.org/Schedules/KDE4/4.2_Feature_Plan

TODO 	 System Settings 	 add Administrator mode button. See Bug 151669 	 Alessandro Diaferia <alediaferia@gmail.com>

It's simply not done yet. Maybe fixed before 4.2, but I doubt it. Probably one or two versions later. The status "new" here is wrong - should be assigned to Alessandro.

Very annoying bug though.
Comment 34 Franz Berger 2009-01-07 11:33:55 UTC
The newest KDE Commit Digest at http://commit-digest.org/issues/2009-01-04/ features "PolicyKit" for Administrator Mode in Applications. It says there will be a library for PolicyKit in 4.3, so I doubt that this bug will be fixed in 4.2.
Comment 35 beojan 2009-01-10 19:33:13 UTC
Well, KDE 4.2 is past Hard Feature Freeze (that's why I added "see Bug 151669" to the feature plan). I still think I would be good if fedora submitted their patch as an interim fix until PolicyKit is integrated, or even if KDE enabled a patch that used PolicyKit if it were found (I've installed the policykit library from playground, and anyone else who is affected could do the same)
Comment 36 Grósz Dániel 2009-01-10 19:38:28 UTC
Using unstable/beta/playground software for security related things is a bit hazardous, isn't it?
Comment 37 beojan 2009-01-11 22:54:56 UTC
PolicyKit itself is fully stable, and is used in fedora. I only compiled the KDE frontend, and even that is from kdereview, not playfround (sorry, I made a mistake before)
Comment 38 Georg Grabler 2009-01-25 05:12:58 UTC
Probably soe day in a 4.2.x release. If Lukas is working on this I'm sure he'll try to get it finished soon - at least that's as I know him ;-).
Comment 39 Paweł Prażak 2009-01-30 12:48:14 UTC
It's resolved in KDE 4.2 by using kdesu, can we close this bug now?
Comment 40 Grósz Dániel 2009-01-30 12:54:52 UTC
I would say yes. It works for me in openSUSE. Is it now distribution-independent?
Comment 41 kujub 2009-01-30 12:58:22 UTC
Fixed ?
I can't change anything in systemsettings Login Manager or Samba because all is greyed out. There is still no Admin Button.

ArchLinux 686
kdebase 4.2.0-1
qt 4.4.3-5
Comment 42 Richard Hartmann 2009-01-30 13:16:08 UTC
If I understood correctly (I installed 4.1.96 & now 4.2 but did not have time to test), it is now possible to start systemsettings via kdesu, thus you can edit stuff as normal user.

If this is the case, I would say the issue needs to stay open until the 2.x/3.x admin button is implemented, as well. The use of kdesu is non-obvious for the average user.
Comment 43 Grósz Dániel 2009-01-30 13:28:43 UTC
@Richard Hartmann:
No, (at least in some distributions, I don't know if it works everywhere) if you run Systemsettings as normal user, and you click on the icon of a module which needs administrative privileges, it asks for the root password and opens the module as root. It is user-frendly. It is slightly different (and thus questionnable from a usability perspective) because it opens the module in a new window, not inside Systemsettings.
Comment 44 Kyle 2009-01-30 13:37:13 UTC
nope, its not like that here (Arch Linux, kdemod 4.2)
Comment 45 Richard Hartmann 2009-01-30 13:58:44 UTC
Openening in a new window is Bad, imo.
Comment 46 kujub 2009-01-30 14:07:50 UTC
There is neither a password question nor a Administrator Mode Button (as stated in the help) here on ArchLinux with KDE 4.2.0 (not mod).
Comment 47 Markos Chandras 2009-01-30 14:11:22 UTC
Neither on Gentoo
Comment 48 Rémi 2009-01-30 15:03:52 UTC
There nothing like that on Mandriva

The current state is a regression. There is an admin button in KDE 3.5 and before. systemsettings in KDE 4.x should have one too.
Comment 49 Paweł Prażak 2009-01-30 15:15:54 UTC
So as it I see from comments, it's openSUSE's specific workaround and not a upstream change. And AFAIR there was not working Administrator Mode button some time ago in 4.x so I think developers are working on it.
Comment 50 Holly 2009-01-30 16:23:56 UTC
Actually, it's been a bit since I checked, but I seem to remember being able to run systemsettings as root in Kubuntu.

However, whenever I did, Samba settings would never be there, so it was pretty useless to me in that regard. It helped me do some other stuff, though.

I'd really just like the admin mode button back. It made everything so simple. As it is now, there's no way to edit Samba settings in KDE4 via the GUI.
Comment 51 beojan 2009-01-31 11:20:46 UTC
(In reply to comment #38)
> Probably soe day in a 4.2.x release. If Lukas is working on this I'm sure he'll
> try to get it finished soon - at least that's as I know him ;-).
> 

Well actually, Lukas only created the workaround patch. This seems to be destined to become a permanent problem
Comment 52 Leos Junek 2009-02-03 18:37:07 UTC
KDE 4.2.0, kernel 2.6.24-gentoo-r3, architecture: amd64
I have no switch button (to get to root mode) in systemsettings. Furthermore
# systemsettings
does not work - no window appears. 
"$ sudo systemsettings" or "$ kdesu systemsettings" works.
It would be great if there is admin button back or if # systemsettings works as it is possible in KDE 3.5.x

Comment 53 Leos Junek 2009-02-03 18:38:21 UTC
KDE 4.2.0, kernel 2.6.24-gentoo-r3, architecture: amd64
I have no switch button (to get to root mode) in systemsettings. Furthermore
# systemsettings
does not work - no window appears. 
"$ sudo systemsettings" or "$ kdesu systemsettings" works.
It would be great if there is admin button back or if # systemsettings works as it is possible in KDE 3.5.x

Comment 54 Pino Toscano 2009-03-15 11:34:09 UTC
*** Bug 187207 has been marked as a duplicate of this bug. ***
Comment 55 Flying Stranger 2009-03-30 22:36:52 UTC
sudo systemsettings
Comment 56 Chad Carew 2009-03-30 23:22:11 UTC
Re: Comment #55. Thanks for that. I'll keep the snarky remarks to myself. It does deserve this though: That isn't a fix for this bug. It is a work-around. Systemsettings can and *should* have a simple admin mode button. I'm perfectly comfortable with a command line, but if there is an elegant way to not deal with the cli, I'm not going to. I say to myself "would I rather click on konsole, then type sudo whatever... or would I rather click an icon, and then click another admin mode button? Hmm.."
Comment 57 Salvo "LtWorf" Tomaselli 2009-03-31 18:58:56 UTC
-_- I can also do su -c vim /home/user/.kde4/share/config....
Do you call it usable?
Comment 58 Pino Toscano 2009-04-17 13:02:13 UTC
*** Bug 189855 has been marked as a duplicate of this bug. ***
Comment 59 André Fettouhi 2009-04-17 14:02:06 UTC
Wasn't there according to the feature plan of KDE 4.2 to be implemented an administrator button?

http://techbase.kde.org/Schedules/KDE4/4.2_Feature_Plan

This is still listed as "to do" and there are a bunch of other things that are listed "to do" or "in progress" are these things then going into KDE 4.3? I looked also at the feature plan for 4.3 and I can't any of the missing features from 4.2 in 4.3. So what will happen to those things? Because 4.2.2 was the last of the 4.2 series, right, before 4.3?
Comment 60 Diego 2009-04-17 14:35:36 UTC
> So what will happen to those things?

According to Dario Freddi the plan is to have these changes in 4.4:
http://drfav.wordpress.com/2009/04/07/a-bunch-of-quick-updates/
«Polkit-qt is shaping up nicely. The bad news is that all the announced support for root controls in systemsettings will be delayed to 4.4. The good news is that you will get much more than what I already talked about. I can’t unveil details right now for obvious reasons but you should see that in the very near future. Again, I will probably write a whole post about that when it’s time.»

> Because 4.2.2 was the last of the 4.2 series, right, before 4.3?

Of course not, but this is not the right place to discuss about these things, please use the forum for these kind of questions:
http://techbase.kde.org/Schedules/KDE4/4.2_Release_Schedule
Comment 61 Grósz Dániel 2009-04-17 15:48:41 UTC
Some distros (including openSUSE) have already solved/worked around the problem in a not optimal but working way. I think something like that should be added to default KDE until the better solution can be used. Simple users (who have no idea about command line) do not need sophisticated features but they _need_ a way to change administrator settings.
Comment 62 Davide Bettio 2009-05-15 00:05:31 UTC
*** Bug 189902 has been marked as a duplicate of this bug. ***
Comment 63 Davide Bettio 2009-05-15 00:06:19 UTC
*** Bug 192719 has been marked as a duplicate of this bug. ***
Comment 64 Ernest N. Wilcox Jr. 2009-05-24 15:54:16 UTC
I am using Mandriva Linux 2009.1 (Spring) final release, and there is still no administrative functionality. Mandriva has discontinued the default inclusion of KDE3 with their installation, so a new user will no longer even be aware that KDE3 could be an option . . .

This bug report was opened November 1, 2007. This is May 24, 2009 (a year and a half later). The status of this bug is still NEW (with NORmal priority) and no one seems to have any idea when (or if) there will ever be a resolution (only vague assurances that we will see even more than we have requested . . .). Assurances are of no value unless they are backed up with some form of firm limitation as th when they will be met, and KDE-4.4.x is too far out to constitute such a commitment. 

I have resorted to editing the menu to add a "Systemsettings Admin" menu item that lets me run system settings as root, but this is still a poor work around for a new user who is not familiar with Linux (or KDE). If adding advancements to a Desktop Environment obfuscates its functionality, I have to ask if the Desktop Environment has advanced (or regressed)?

Based on the evidence I see in this bug report, the ability of a novice user to administer the system is not a high priority, or at least not as important as it should be.

Please understand that my intention is not to offend any one. If I have, I sincerely apologize. I simply request that the development team give this issue a higher priority because it negatively impacts new users (and their impression of KDE).
Comment 65 Jonas Vejlin 2009-05-24 16:31:44 UTC
some bug is awfol long time to fix. They must be hard to solve
Comment 66 Grósz Dániel 2009-05-24 16:36:48 UTC
Actually openSUSE has practically solved it (even if it is more a workaround), just KDE devs don't bother to temporarely integrate it. Other distros should use the openSUSE patch.

Btw I don't know but I doubt that the old KControl solution would be so damn hard to do, they just want to wait for one more framework to have some extra features that no one needs.
Comment 67 Paweł Prażak 2009-05-24 16:43:46 UTC
(In reply to comment #65)
> some bug is awfol long time to fix. They must be hard to solve
Yeh, that's an awfully awful time-consuming huge mega bug ;P common...

(In reply to comment #66)
There was a workaround in openSUSE, but it's gone in 4.3beta (dunno why).

(In reply to comment #64)
Maybe it would help thing a bit if we start to complain to the distros,
especially those that want to be considered "easy to use" (like e.g. kubuntu,
mandriva, etc...) and they will help KDE people to solve it.

It's ridiculously old bug with very little attention from the devs. I
understand that some things are not so easy to fix and all that, but common
over a year?! 

Some status update would be nice, is it assigned to anyone? Was works started?
Or just mark it "DONT_CARE/GTFO" :F
Comment 68 Valentyn Pavliuchenko 2009-05-24 19:39:11 UTC
> Some status update would be nice, is it assigned to anyone? Was works started?
> Or just mark it "DONT_CARE/GTFO" :F

Fully agree. Please pronounce "We don't care about this report with 1751 votes, we want fucken bells and whistles. We don't care about users" and mark a bug WONTFIX.

Sorry, but we don't need it in KDE 4._current+2_, we need it NOW.
Comment 69 Georg Grabler 2009-05-24 19:54:19 UTC
Guys guys. First of all, for fixing this bug there was a own library developed "qPolicyKit" / "kPolicyKit", and there have been several blogs about the project status. As far as I know this is finished. As far as I know, they're not far from fixing this one, and yes, it consumed time.

It's still a open source project. Allthough, this is something which should have been covered with 4.0. Anyway, there are workarounds for this (sudo systemsettings), and policykit wasn't in a really usable state when KDE4 was released.

Please, show a bit patience. The guys are not paid to work on this features, and just because you don't see the work does not mean it's not being worked on. They are, and the KDE guys are doing a great job - also on this, even when it takes a bit longer this time.
Comment 70 Grósz Dániel 2009-05-24 20:08:29 UTC
Well, KControl had administrator mode without PolicyKit.
Comment 71 Georg Grabler 2009-05-24 20:21:27 UTC
And kControl is not SystemSettings, as simple as it is.
Comment 72 Grósz Dániel 2009-05-24 20:25:34 UTC
I thought it was obvious that I meant that it could been done without polkit, so it could've been done without polkit also in Systemsettings.
Comment 73 Sergei Andreev 2009-05-24 20:25:47 UTC
>Well, KControl had administrator mode without PolicyKit.

Well, in Kubuntu I have administrator mode in System Settings without PolicyKit too.
Comment 74 Paweł Prażak 2009-05-24 20:26:33 UTC
(In reply to comment #69)
> Guys guys. First of all, for fixing this bug there was a own library developed
> "qPolicyKit" / "kPolicyKit", and there have been several blogs about the
> project status. As far as I know this is finished. As far as I know, they're
> not far from fixing this one, and yes, it consumed time.
> 
> It's still a open source project. Allthough, this is something which should
> have been covered with 4.0. Anyway, there are workarounds for this (sudo
> systemsettings), and policykit wasn't in a really usable state when KDE4 was
> released.

Than why this bug's status is NEW? not WORKINPROGRESS/ASSIGNED or whatever
 
> Please, show a bit patience. The guys are not paid to work on this features,
> and just because you don't see the work does not mean it's not being worked on.

Please take into account that people are (were) patient for over a year now. :|

> They are, and the KDE guys are doing a great job - also on this, even when it
> takes a bit longer this time.

No one is questioning that KDE devs are doing great job (we wouldn't use it if that would be the case ;P), but they are not so good at informing people about this bug's status, which pisses off a lots of people (see the CC list, it's really long and +1700 votes... and thats only people who care enough to report bugs), I think they deserve a simple "it's OK people, we're working on it, it will be in 4.3.x". Can someone please at least change bug status, it's 5 seconds to do it :)
Comment 75 Maciej Pilichowski 2009-05-24 20:36:11 UTC
> I think they deserve a simple "it's OK people, we're working on it, it
> will be in 4.3.x".

You mean they deserve a lie?

I get today around 10 messages from this report, all of them fruitless. Instead of writing long memos about changing the status (the status is NEW and it won't be confirmed any any further), do it yourself. Go ahead, grab the code, and do it. Everybody will be grateful.

There are tons of issues on BKO, there are tons of issues in ML, complaining "look at _this_ report, is important" does not any good. Understand the simple fact, that number of developers is by several orders of magnitude smaller than number of reports! Do the math -- thank you in advance.
Comment 76 Georg Grabler 2009-05-24 20:52:22 UTC
First of all, this task hasn't been assigned to any special person. As far as I know, there are more than 3 people working on this. It is split into several, completely different tasks (first of all the implementation of policykit, which was finished, and merged by drf as I know. Secondly, the implementation of this into kdeadmin .. not sure if there's anybody who feels he can do this alone, since kdeadmin has a lot of parts, where different people are responsible for).

From what I've read, the implementations of kcontrol, the patches of opensuse, kubuntu etc. are pure hacks. Nothing more or less.

Now, as the speaker before said. Grab the code, make it happen faster. In cases like this, I experienced that the guys will be faster than yourself, except if you're coming with a vast knowledge about all this.
Comment 77 Jonas Vejlin 2009-05-24 21:52:25 UTC
About grepping the code and do it ourself: What about the "huge" amount of useers there do not know to code?
Comment 78 Paweł Prażak 2009-05-24 23:08:46 UTC
(In reply to comment #75)
> > I think they deserve a simple "it's OK people, we're working on it, it
> > will be in 4.3.x".
> 
> You mean they deserve a lie?

(In reply to comment #76)
> First of all, this task hasn't been assigned to any special person. As far as I
> know, there are more than 3 people working on this. It is split into several,
> completely different tasks (first of all the implementation of policykit, which
> was finished, and merged by drf as I know. Secondly, the implementation of this
> into kdeadmin .. not sure if there's anybody who feels he can do this alone,
> since kdeadmin has a lot of parts, where different people are responsible for).

Now I'm confused about the status, are they working on it or not? ;)

> From what I've read, the implementations of kcontrol, the patches of opensuse,
> kubuntu etc. are pure hacks. Nothing more or less.

It's obvious they are hacks, but isn't it all the regular user needs until the devs get the implementation to the perfection? ;) Whats wrong in having WORKING temporary hack, instead of non working admin panel?

> Now, as the speaker before said. Grab the code, make it happen faster. 
> In cases like this, I experienced that the guys will be faster than yourself, > except if you're coming with a vast knowledge about all this.

I'd love to if I only had more time. There's no point in being offensive, all I wrote was the truth, there is confusion in community about this issue and it needs to be sorted out thats all. If you would read my comments carefully you would see that all I'm saying is that people wants to know whats going on with this feature and when it will be ready, is that so rude to ask why +1 year old bug report has NEW status? Doesn't +1700 votes not count for CONFIRMED? You say that 3 people are working on it, thats great news, but why this bug report don't reflect this? Simple questions, thats all.
Comment 79 Georg Grabler 2009-05-24 23:59:49 UTC
First of all, assigning the task to one person when multiple persons work on it is pointless, and yes, it's being worked on. Yes, it should and could be confirmed, but I'm not sure if you need to assign somebody if you confirm it (i'm not a kde dev, just following closely spending some time on patches).

What ever the tracker says, but looking a bit closer, it's in the 4.2 features list (!), even referring to this bug ID. There is a contact person assigned there (Alessandro Diaferia).
Following the path down, you can see that the qPolicyKit integration is done, and the kPolicyKit integration is in progress - what will be the base of the admin mode. Allthough, I doubt it will be done in 4.2 still (4.2.4?).

Secondly, probably more important for a personal reason, it wasn't meant in an offensive way what I wrote, and I'm sorry if it seemed offensive. But it's what I experienced, working on the same thing in a schedule "against" persons who do this for a way longer than I is most likely a lost situation. That's why I wrote "I experienced".
You personally say you're short of time. There are plenty others complaining about this bug, and I understand (as I don't bring the skills myself - I think, never looked at it though since I know that it's being worked on) that some of them do not have the skills to help.
But as you can expect, you're not the only person short of time, also the developers, since most are not paid for their work on KDE, are also busy with their lifes and jobs.
Some of the KDE devs are powered by Novell, who originally wrote the patch for the administrator mode in KDE 4. I think there are reasons why it got refused to get into the KDE mainstream code.
Comment 80 Ben Cooksley 2009-05-25 06:12:35 UTC
The reason plain and simple why KControl supported "Administrator Mode" was because it implemented a hack which used KDESu to run the module as root then performed an XEmbed into its own window. It didn't work consistently either.

This method was not possible in KDE 4 because it is multi platform and XEmbed is only possible on X server based systems.

Not to mention it is a bad idea to run graphical applications as root anyway.
This feature must be implemented using a PolicyKit type system in the modules individually ( or the external apps feature being added to 4.4 being abused )
Comment 81 Paweł Prażak 2009-05-25 08:37:32 UTC
(In reply to comment #79)
> What ever the tracker says, but looking a bit closer, it's in the 4.2 features
> list (!), even referring to this bug ID. 
Yes, that's what I've remembered that this bug was suppose to be fixed in 4.2.

> Following the path down, you can see that the qPolicyKit integration is done,
> and the kPolicyKit integration is in progress - what will be the base of the
> admin mode. Allthough, I doubt it will be done in 4.2 still (4.2.4?).
So it seams that resolution is closer to the end.

> But as you can expect, you're not the only person short of time, also the
> developers, since most are not paid for their work on KDE, are also busy with
> their lifes and jobs.
Yes, I fully understand that and I'm grateful for their time and effort.

Enough talking, it's time to find and patch some bugs ;)
Comment 82 A. Spehr 2009-05-25 10:48:44 UTC
You should realize that not every development project in kde uses "assigned". This bug has several developers on the cc:, it has *blog* entries of people talking about working on it per comment #69, so obviously people know about it and are working on it: what more do you want? If you want to just complain somewhere, don't do it on this report, it is for *bugs*. Trashing the developers working on it is not motivating. If you would like to help KDE but can't code, you can always do: bug triage (with bugsquad), documentation, artwork, translation, promotion/demos/talks and marketing (help us get more coders/etc), usability, accessibility(!!!), etc., etc. 


Furthermore, what individual distros do or don't do doesn't matter here, this is upstream KDE. So confirming anything here, that is *not* a pure trunk build is pointless. And no, it isn't implemented yet.
Comment 83 Salvo "LtWorf" Tomaselli 2009-05-25 11:00:44 UTC
He just wants the bug to be confirmed, not assigned. And i agree with him.
Comment 84 Pino Toscano 2009-05-25 11:28:12 UTC
> He just wants the bug to be confirmed, not assigned. And i agree with him.

Bug status is NEW, which already means "confirmed".
Comment 85 Grósz Dániel 2009-05-25 12:38:06 UTC
#82: what individual distros have does matter because if they have a working workaround (as openSUSE has), it could be taken temporarily by upstream KDE until a better solution is made.
Comment 86 Paweł Prażak 2009-05-25 14:22:51 UTC
(In reply to comment #82)
> You should realize that not every development project in kde uses "assigned".
> This bug has several developers on the cc:, it has *blog* entries of people
> talking about working on it per comment #69, so obviously people know about it
> and are working on it: what more do you want? If you want to just complain
> somewhere, don't do it on this report, it is for *bugs*. Trashing the
> developers working on it is not motivating. 

I confused NEW with UNCONFIRMED (surely I need more sleep ;)
NEW == CONFIRMED I get it :)

Nobody's trashing anyone, it's just a matter of communication, I know that day have only 24h and most of them are already taken by work/sleep/life and there is always not enough time :|

Please note that this discussion would never happen if there was some feedback in this report about status, to ensure people that the solution is being work upon, it takes only a minute to do it.

OK, maybe I overreacted, shit happens, but now at least we know whats the status and thats important IMHO, because healthy community is about communication and feedback.

> If you would like to help KDE but
> can't code, you can always do: bug triage (with bugsquad), documentation,
> artwork, translation, promotion/demos/talks and marketing (help us get more
> coders/etc), usability, accessibility(!!!), etc., etc. 

For that matter, I regularly fill bug reports, test factory repo, and if I have enough time I fix bugs and send patches, and I encourage everyone to do the same. :) 

Now, I think everybody are happy ;)
Comment 87 Tony White 2009-05-25 14:33:22 UTC
The schedules, http://techbase.kde.org/Schedules/KDE4/4.3_Feature_Plan#kdebase-workspace.

IN PROGRESS 	KControl4 	Import refactor of systemsettings with Tree and Icon view support

So if this feature was a kcontrol feature, would it not make perfect sense that it will be worked into kcontrol4, without any need to sulk or stamp feet.
Comment 88 Georg Grabler 2009-05-25 14:36:34 UTC
(In reply to comment #85)
I agree with you that it could make sense, but in this particular case it does not make sense. As Ben wrote in comment #80, KDE is cross platform, using X-Server specific patches isn't a solution in any case (probably wouldn't even compile on windows).

I completely agree with comment #82, discussions like this should not be held here but on the mailing lists.
Comment 89 Georg Grabler 2009-05-25 14:41:59 UTC
Just to add here... the commit digest 2009-01-04
http://commit-digest.org/issues/2009-01-04/
That's where I read something about this the first time, and the devs actively called for help on this.
Comment 90 Grósz Dániel 2009-05-25 15:04:10 UTC
Users not need the administrative modules on Windows/OS X because they use the OS's administration tools. (And KDE 4.3 for those platforms, unlike for X11, still won't be supposed to be ready for typical desktop users, will it?)

Btw (currently) policykit is also only for Unix-like systems, isn't it?
Comment 91 Ben Cooksley 2009-05-26 06:02:59 UTC
@Comment #87: KControl4 was merged in as System Settings shortly before the hard feature freeze. The KControl reference was simply because it supported the Tree View. No hack will be added.

- System Settings Maintainer
Comment 92 Christoph Feck 2009-05-27 00:38:36 UTC
*** Bug 194216 has been marked as a duplicate of this bug. ***
Comment 93 Tony White 2009-05-27 02:11:03 UTC
Ben, please for the benefit of the many, either mark this report as WONTFIX or enlighten us with some clarity. :)
All code is considered some sort of "Hack" In the view (Of many) Of the hackers that make up foss, so either yes, we know, it's on it's way or sorry guys, it's not happening?

My personal view is not fussed and indifferent, however there are obviously others wasting their time reporting it here and they seem unhappy about it.
So, do you think it will be possible for you to add this kde3 feature to kde4?
Comment 94 Ben Cooksley 2009-05-27 05:43:41 UTC
This feature will be implemented using PolicyKit, which means user interfaces do not have to run as root, and Administrators will have greater power over allowing users to manage their systems.

Unfortunately, due to time constraints, this will not be implemented in KDE 4.3. It requires changes to all modules that need Administrator mode support.
No time frame is available at this stage.
Comment 95 Valentyn Pavliuchenko 2009-05-27 10:21:44 UTC
Ben, will it be backported to 4.3 when it will be done?
Comment 96 Ben Cooksley 2009-05-27 12:05:34 UTC
It will likely involve string changes, or the changes will be too invasive to backport. It will not be known if it is backportable until it is actually done.
Comment 97 Pino Toscano 2009-05-29 10:45:01 UTC
*** Bug 194519 has been marked as a duplicate of this bug. ***
Comment 98 David 2009-06-02 10:40:25 UTC
Same problem here
Mandriva 2009.1
   KDE 4.2.2
ArchLinux
   KDEmod

I must be going blind, how do I vote on this thing....
Comment 99 Jonas Vejlin 2009-06-02 11:06:32 UTC
#98 at the top of the bugreport there is a blue box. At the button of it there is a link where you can vote
Comment 100 David 2009-06-03 03:57:35 UTC
Thanks.
Yeah it wasn't there til I commented and thus become subscribed. That was tougher than it should have been.
Comment 101 Andreas Stangl 2009-06-06 11:57:19 UTC
In the latest Kubuntu release policykit seems to be integrated in the systemsettings. There is no need to enter the root password anymore. Is this still a hacky approach?
Comment 102 David Rankin 2009-07-22 04:25:09 UTC
4.2.96 and still not working...
Comment 103 Ben Cooksley 2009-07-22 05:41:16 UTC
@Everyone: This bug will be updated when progress is made. In 4.4 a authentication framework, written by a GSOC student will hopefully be imported allowing progress.
Comment 104 Dario Andres 2009-07-25 23:22:50 UTC
*** Bug 201421 has been marked as a duplicate of this bug. ***
Comment 105 Andreas Stangl 2009-08-15 16:48:59 UTC
as policykit-kde is now available in kde-4.3 I wonder why another authentication framework needs to be implemented for kde 4.4...
Comment 107 Diego 2009-08-16 09:24:01 UTC
And here:
http://www.gigabytes.it/2009/08/kde-authorization-library-final-step/
"As part of my work I’ve ported the date/time kcm module to the new library. Its code already followed the caller/helper pattern, but authorization used kdesu and data was passed using commandline arguments. The new code saves some lines of code and seems a bit cleaner."
Comment 108 Evgeny Tikhonov 2009-09-01 18:59:17 UTC
Why this EPIC bug hasn't even been assigned???????
Comment 109 Diego 2009-09-01 19:19:30 UTC
Probably because it depends on the work of several developers, I think.
However it's sort of fixed:
http://drfav.wordpress.com/2009/08/31/tokamak-kauth-into-kdelibs/
Comment 110 Dave Plater 2009-09-01 19:32:33 UTC
it's fixed in opensuse.
Comment 111 mb1 2009-09-01 23:29:39 UTC
@Evgeny: Why this EPIC bug hasn't even been assigned???????

As I recall Admin Mode was scheduled to be added in KDE4.3...the deadline flew by and it did not get done...last I heard it was on the To-Do list for KDE4.4

@Dave Plater

Odds *buntu and OpenSUSE made their own patch because they got impatient with no progress on the matter.
Comment 112 Ben Cooksley 2009-09-02 02:11:16 UTC
With the KAuth framework, System Settings is actually now equipped for "Administrator mode" all that is needed is appropriate support added to the KControl modules that need it. Therefore this bug is "fixed" in a sense.

@mb1: Yes openSUSE / Kubuntu are including are Root mode hack in System Settings, which will hopefully be removed with KDE 4.4.
Comment 113 Holly 2009-09-02 03:44:41 UTC
Arch Linux's KDEMod (Chakra) also has a root dialogue appear whenever you go into root areas like Samba.

That's good enough for me for now.
Comment 114 mb1 2009-09-02 06:01:08 UTC
@Holly

Ah, so THAT is one of the patches the Chakra guys put on Vanilla KDE on Arch. We wonder sometimes just where they do patch things :>)


It ain't there on Vanilla KDE on Arch tho' of course.
Comment 115 Holly 2009-09-02 06:18:17 UTC
Yeah, I didn't think it would be.

I'm pretty sure the other patches just make it run faster. The website might have a list of the optimizations or something. I've not used vanilla KDE in Arch so I dunno the differences in performance.
Comment 116 Maciej Warnecki 2009-09-02 07:30:00 UTC
For me, it isn't a big performance difference, if any (Arch Kdemod).


But the fact is, that after update to KDE 4.3.1, I am prompted for root password when I try to open Login screen settings from KCM, and that's just what I wanted (In 4.3, all options were simply greyed out, and no root prompt)
Comment 117 FiNeX 2009-09-03 19:26:59 UTC
Administrator mode has been implemented in trunk. It will be available in KDE 4.4 and it will not be backported to 4.3.

Thanks to Dario F. for the development :-)
Comment 118 Dario Andres 2009-12-13 00:18:14 UTC
*** Bug 218381 has been marked as a duplicate of this bug. ***
Comment 119 Dario Andres 2009-12-13 13:54:14 UTC
*** Bug 218381 has been marked as a duplicate of this bug. ***
Comment 120 pp.f. 2009-12-23 12:48:25 UTC
*** Bug 219818 has been marked as a duplicate of this bug. ***
Comment 121 Rémi 2010-02-05 08:59:15 UTC
One year later, I don't see any admin mode :x
I am using Mandriva's binary (KDE 4.4 RC3).
Comment 122 Ben Cooksley 2010-02-05 09:50:18 UTC
As stated previously, System Settings will ask for elevated privilages only when needed and no longer has an explicit button to elevate privilages.
Comment 123 Pete Miller 2010-02-05 10:21:50 UTC
> --- Comment #122 from Ben Cooksley <sourtooth gmail com>  2010-02-05 09:50:18 ---
> As stated previously, System Settings will ask for elevated privilages only
> when needed and no longer has an explicit button to elevate privilages.

I don't see it. I just tried yesterday on the current Mandriva Cooker
and all the KDM settings are all grayed out still with seemingly no
way to edit them. Is there something I'm missing?
Comment 124 Ben Cooksley 2010-02-05 10:35:19 UTC
This is either because the KDM control module hasn't been ported to KAuth yet or due to a bug in your PolicyKit configuration.
Comment 125 m.wege 2010-02-05 10:37:33 UTC
I just tested in on Kubuntu 4.4 RC2. It seems ok to me there. Everywhere where it is needed, I am asked for the password. If it does not work on Mandriva, you need to report it to their bug tracker.
Comment 126 Bobby 2010-02-05 10:51:48 UTC
Am Freitag 05 Februar 2010 08:59:24 schrieb Rémi:
> https://bugs.kde.org/show_bug.cgi?id=151669
> 
> 
> 
> 
> 
> --- Comment #121 from Rémi <remi assailly free fr>  2010-02-05 08:59:15 ---
> One year later, I don't see any admin mode :x
> I am using Mandriva's binary (KDE 4.4 RC3).
> 
Works fine on openSuse 11.2 with the stable version, but I haven't had any luck 
with 4.4 either. I guess it will be back in the final version though.
Comment 127 Martin L ü c h e m 2010-02-05 11:02:36 UTC
(In reply to comment #122)
> As stated previously, System Settings will ask for elevated privilages only
> when needed and no longer has an explicit button to elevate privilages.

I cannot see that either! 

Version:           1.12.4 (using 4.3.4 (KDE 4.3.4), Debian packages)
Compiler:          cc
OS:                Linux (x86_64) release 2.6.30-2-amd64

So why is this "fixed"?

Martin
Comment 128 Martin L ü c h e m 2010-02-05 11:23:56 UTC
(In reply to comment #124)
> This is either because the KDM control module hasn't been ported to KAuth yet
> or due to a bug in your PolicyKit configuration.

Ok, Ben, is this a workround or do you tell us the solution. Sorry, this shall not sound unfriendly but this bug is quite awful, because a lot of us out there will not know how to configure some settings without a solution for this bug! This is  bit like throwing away the key for the car trunk and telling the driver: "Sorry but this is open source!" ;-) And we all know that this has  interdependences with the use of "sudo", "sux", etc.

My question on the PolicyKit configuration: Can you give us a hint which screw to turn (in Germany we say so: "an welcher Schrube wir drehen sollen") around here? 

Thank you for your help!  Martin
Comment 129 Ben Cooksley 2010-02-05 12:01:33 UTC
The Bug itself, regarding System Settings having no way to run commands that needed elevated privilages is fixed by KAuth.

KAuth has no visual signs of its presence other than "Apply" having a lock icon if you need to authenticate.

Any issues you are having with the KDM control module and its inability to gain privilages is a seperate bug with it.

Unfortunately I don't know much about PolicyKit itself, however the Clock KCM is known to work. If it doesn't, please file a bug report with your distribution.

As an alternative, run kdesu kcmshell4 kdm
Comment 130 Valentyn Pavliuchenko 2010-02-05 12:02:42 UTC
> I cannot see that either! 

> Version:           1.12.4 (using 4.3.4 (KDE 4.3.4), Debian packages)
> So why is this "fixed"?

Fixed in 4.4. Wait for it few days:)
Comment 131 Martin L ü c h e m 2010-02-05 12:18:34 UTC
(In reply to comment #130)
> > I cannot see that either! 
> 
> > Version:           1.12.4 (using 4.3.4 (KDE 4.3.4), Debian packages)
> > So why is this "fixed"?
> 
> Fixed in 4.4. Wait for it few days:)

What does "a few days" mean! ;-) Martin
Comment 133 Martin L ü c h e m 2010-02-05 12:56:51 UTC
Hi Ben!
(In reply to comment #129)
> The Bug itself, regarding System Settings having no way to run commands that
> needed elevated privilages is fixed by KAuth.
> 
> KAuth has no visual signs of its presence other than "Apply" having a lock icon
> if you need to authenticate.
> 
> Any issues you are having with the KDM control module and its inability to gain
> privilages is a seperate bug with it.
> 
> Unfortunately I don't know much about PolicyKit itself, however the Clock KCM
> is known to work. 

What is "Clock KCM"?

> If it doesn't, please file a bug report with your
> distribution.
> 
> As an alternative, run kdesu kcmshell4 kdm

Yes, this works! But this is only one example "kdm". How do I know which other
elements to start?

Thank you again! Martin
Comment 134 Rémi 2010-02-05 13:38:27 UTC
> As stated previously, System Settings will ask for elevated privilages only when needed and no longer has an explicit button to elevate privilages.

How can I be asked for elevated privilages if I am unable to change anything ?
;)

Tools for SAMBA or KDM have been read only since KDE 4.0. But is still the
same, unfixed...

> Works fine on openSuse 11.2 with the stable version, but I haven't had any luck with 4.4 either. I guess it will be back in the final version though.

Working on opensuse does not seem working upstream ;)
Bug 180437 is a good example, works very well on mandriva cooker, do not seem to be fixed upstream :)
Comment 135 Bobby 2010-02-05 14:05:34 UTC
Am Freitag 05 Februar 2010 13:38:34 schrieb Rémi:
> https://bugs.kde.org/show_bug.cgi?id=151669
> 
> 
> 
> 
> 
> --- Comment #134 from Rémi <remi assailly free fr>  2010-02-05 13:38:27 ---
> 
> > As stated previously, System Settings will ask for elevated privilages
> > only when needed and no longer has an explicit button to elevate
> > privilages.
> 
> How can I be asked for elevated privilages if I am unable to change
>  anything ? ;)
> 
> Tools for SAMBA or KDM have been read only since KDE 4.0. But is still the
> same, unfixed...
> 
> > Works fine on openSuse 11.2 with the stable version, but I haven't had
> > any luck with 4.4 either. I guess it will be back in the final version
> > though.
> 
> Working on opensuse does not seem working upstream ;)
> Bug 180437 is a good example, works very well on mandriva cooker, do not
>  seem to be fixed upstream :)
> 
I do hope that things will change with the 4.4 release because this bug is as 
old as KDE 4.0. It's full time for it to work on all Distros. I don't know if 
it's the KDE devs fault at this point or the Distros fault because like I 
said, I have no problem with the stable version on openSuse. If I click on  
Login Manager or Yast module in the KDE System Settings then i get a little 
window prompting me to enter my root password. There is no button available. 
It doesn't work in 4.4 though. Don't know why.
Comment 136 Grósz Dániel 2010-02-05 16:32:30 UTC
#135: It is the fault of both KDE and distros. openSUSE did a temporary patch (probably not applied to development releases); KDE should have incorporated such a temporary workaround and as KDE didn't, other distros should have done so.
Comment 137 Ben Cooksley 2010-02-05 22:15:49 UTC
Clock KCM = Date & Time.

openSUSE & Kubuntu ( and probably Mandriva ) patch System Settings to launch certain modules with kdesu, this is noticable when they are seperate windows and not integrated into System Settings itself. Their 4.4 packages probably don't contain this patching.

Just to make it clear: Administrator Mode in KDE 4 will never have a seperate button simply because it is not needed. 

Modules inform System Settings if they need authentication and it will take care of launching their helper as root via PolicyKit and D-Bus to perform the action safely and securely when you click Apply.

If the modules don't allow you to change anything then that is a bug with them, please file one.

You can use kcmshell4 --list to get a list of modules, just look for the one you need and take the appropriate name.
Comment 138 Bobby 2010-02-06 05:21:41 UTC
Am Freitag 05 Februar 2010 22:16:05 schrieb Ben Cooksley:
> odules inform System Settings if they need authentication and it will take
> care of launching their helper as root via PolicyKit and D-Bus to perform
>  the action safely and securely when you click Apply.
> 
Why should these distros patch something that is working? Without this patch 
there is no way to that one can make certain changes without the console.
Comment 139 Ben Cooksley 2010-02-06 08:05:14 UTC
Distributions need to do absolutely no patching for modules which already use KAuth, as they work internally in the manner I described.

For as yet unported modules, Distributions should alter the *.desktop files to use System Settings External Application Launching infrastructure, so no patching of System Settings itself should be needed in 4.4.

NOTE: The KAuth infrastructure I describe was only added in KDE SC 4.4!
Comment 140 Andrey Borzenkov 2010-02-06 08:13:18 UTC
(In reply to comment #139)
> For as yet unported modules, Distributions should alter the *.desktop files to
> use System Settings External Application Launching infrastructure, so no
> patching of System Settings itself should be needed in 4.4.
> 

Could you please give a (link to) example of such .desktop file, with brief comment of which entries should be added?
Comment 141 Ben Cooksley 2010-02-06 08:30:42 UTC
Please see http://websvn.kde.org/trunk/KDE/kdebase/workspace/systemsettings/examples/external-application.txt?revision=1020026&view=markup

Essentially just make sure the following line is present:

X-KDE-ServiceTypes=SystemSettingsExternalApp

and make sure X-KDE-ServiceTypes isn't set elsewhere in the file.
To make a module launch as root, change the Exec= line as needed.
Comment 142 Andrey Borzenkov 2010-02-06 08:45:18 UTC
(In reply to comment #141)
> Essentially just make sure the following line is present:
> 
> X-KDE-ServiceTypes=SystemSettingsExternalApp

May be I misunderstood you. When I do it, I simply get external window (instead of embedded in system settings) with all the same issues - cannot change anything.

Or do you mean that I need to do this *and* use kdesu at the same time?

But then how can I make resulting window embedded in System Settings?
Comment 143 Ben Cooksley 2010-02-06 08:55:45 UTC
It is not possible to embed the resulting window as it is an entirely seperate application.

To run it as root, you will need to add kdesu to the front of the executed command.
Comment 144 Oswald Buddenhagen 2010-05-24 10:07:28 UTC
SVN commit 1130018 by ossi:

make kcm_kdm use kauth

this finally restores the ability to change kdm settings in a
straight-forward way.

BUG: 236415
CCBUG: 151669

patch mostly by
CCMAIL: Igor Krivenko <igor@shg.ru>
Review-URL: http://reviewboard.kde.org/r/3631/

 M  +8 -0      CMakeLists.txt  
 M  +2 -11     background.cpp  
 M  +1 -2      background.h  
 AM            helper.cpp   [License: GPL (v2+)]
 AM            helper.h   [License: GPL (v2+)]
 A             kcmkdm_actions.actions  
 M  +0 -17     kdm-conv.cpp  
 M  +0 -1      kdm-conv.h  
 M  +9 -33     kdm-dlg.cpp  
 M  +0 -1      kdm-dlg.h  
 M  +0 -12     kdm-gen.cpp  
 M  +0 -1      kdm-gen.h  
 M  +0 -13     kdm-shut.cpp  
 M  +0 -1      kdm-shut.h  
 M  +85 -20    kdm-theme.cpp  
 M  +1 -1      kdm-theme.h  
 M  +72 -36    kdm-users.cpp  
 M  +1 -2      kdm-users.h  
 M  +93 -14    main.cpp  
 M  +8 -0      main.h  
 M  +1 -2      positioner.cpp  
 M  +0 -2      positioner.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1130018
Comment 145 Enzo 2010-10-15 06:59:06 UTC
The problem IS NOT FIXED AT ALL and is still here in 4.5.1.
For example, you cannot set any system network connection!
Sounds a little bit ridiculous.
Any chance to see this fixed in less than 3 years?
Comment 146 Ben Cooksley 2010-10-15 07:28:58 UTC
This is fixed, as previously noted. It is up to individual modules to add KAuth support for any privileged operations.
Comment 147 Jaak Ristioja 2010-10-15 08:00:36 UTC
(In reply to comment #146)
> This is fixed, as previously noted. It is up to individual modules to add KAuth
> support for any privileged operations.

As long as those individual modules are part of KDE it is still a KDE problem that is NOT FIXED. So I suggest the KDE team to actually do something to fix this or face the discontent and loss of users due to the poor quality of the piece of software they provide.
Comment 148 Ben Cooksley 2010-10-15 08:21:40 UTC
Modules with issues need seperate bug reports filed against them.
Comment 149 Jaak Ristioja 2010-10-15 08:31:00 UTC
(In reply to comment #148)
> Modules with issues need seperate bug reports filed against them.

Yes. Is the KDE team going to wait until users report all such modules or are they able to do their QA internally?

Please also post the list of separate bug reports here.
Comment 150 Ernest N. Wilcox Jr. 2010-10-15 08:42:45 UTC
So, re-submit your complaint, but make it clear that the issue is not with
system settings itself, but with the module that has not added KAuth support.
Unless your report is directed to the maintainer of the module causing your
issue, it is unlikely that it will ever get fixed. When the triage team looks
at bug reports, they direct the report to the maintainer of the project named
in the report. If the report names the wrong project, it gets directed to the
wrong maintainer.

If the maintainer of the problem project does not know about an issue, (s)he
will not know to fix it. KDE is a very large organization. Most of the people
who maintain the software are volunteers. They work a full time job to support
themselves, then when they are not working that full time job, they work on the
project for which they have volunteered. They do not have the time it would
require to go looking for bugs they have not been informed about (and why would
they?). I for one am most grateful that they put in the amount of time they do.
Since we (the KDE user community) benefit from their efforts at no cost to us,
I think that the least we can do is to put in the effort to help them (the KDE
development community) by re-submitting bug reports with better information
when we learn that our report has not been directed to the maintainer who can
fix the problem.

I hope I have not offended anyone with this post. I only want to help those new
to Open Source Software better understand how it works. If I have offended
anyone, please accept my apologies.
Comment 151 Bobby 2010-10-15 09:00:50 UTC
Am Freitag 15 Oktober 2010, 08:31:01 schrieb Jaak Ristioja:
> https://bugs.kde.org/show_bug.cgi?id=151669
> 
> 
> 
> 
> 
> --- Comment #149 from Jaak Ristioja <Ristioja gmail com>  2010-10-15
> 08:31:00 --- (In reply to comment #148)
> 
> > Modules with issues need seperate bug reports filed against them.
> 
> Yes. Is the KDE team going to wait until users report all such modules or
> are they able to do their QA internally?
> 
> Please also post the list of separate bug reports here.

This Administrator mode bug is around since KDE 4.0. Sometimes I get the 
impression that features are more important than ironing out the glitches. 
There are a few other little things that are around for years now and nerve 
but nobody seems to care about fixing them.
KDE 4 has more than enough killer features. What users really need is speed, a 
reliable and very responsive desktop.  Get these things in KDE 4 right and it 
will be the clear winner.
Comment 152 Ben Cooksley 2010-10-15 09:35:11 UTC
As far as I am aware, no module currently shipped is broken due to the loss of Administrator mode. KDM and Clocks, the only two modules which used it, have since been fixed. 

Network Management is a seperate issue as System Connections have to be created in a different manner to User Connections.

Please report those modules which still have issues as seperate bugs.
Comment 153 ciraci.f 2012-01-24 19:42:44 UTC
i can't change photo of my account with systemsettings, also if i open with sudo, sudo -s.

it says to me that the admin does't want that i change the photo... but i'm the administator!!!
Comment 154 quazgar 2012-01-25 17:02:24 UTC
(In reply to comment #153)
> i can't change photo of my account with systemsettings, also if i open with
> sudo, sudo -s.
> 
> it says to me that the admin does't want that i change the photo... but i'm the
> administator!!!

Hello,
that sounds like a different problem.  Please open a new bug against this issue.