[UIFE/FFE] At login screen, error message when choosing wi-fi network without stored password

I am not sure this is a good fix, because an error message is an opportunity to tell the user how to fix the problem. If the entries are made "insensitive", how will the user find out how to enable them?

Totally agreed, this fix doesn't seem like the best solution; instead I'd recommend handling this properly in the policykit policy and making sure the user is prompted for an "admin user" password to be able to create arbitrary connections (those that aren't already connected) rather than simply returning with the current error message.

I totally agree that the error message in lightdm when clicking a wireless network that isn't previously created is unsightly, but I really think we should avoid having the user get into an "admin" account, add the network, and disconnect to be able to do whatever they might want to do in the greeter. The current error is also pretty vague, and doesn't provide a hint to the user as to how to fix the issue. Unfortunately, it can't be changed in place because that message is reused in different contexts for insufficient privileges out of a policykit action, which is why the behavior in greeter mode should be fixed up.

Any change for fixing this would require a Freeze Exception; subscribing the release team.

I don't argue that the current work flow of first configuring the access points in normal user session or guest session with auth_admin is somewhat counterintuitive in the situation that the user just looks at the access points in the greeter and wonders why he can't connect to them.

But, changing the policykit rules and introducing the policykit permission dialog at this stage of 12.10 cycle is something I would rather not do. Also this is something that needs input from the design team as they are responsible of the ThinClient / RemoteDesktop feature.

I see three possible solutions:

1)
 - include the patch that makes the APs missing a configuration insensitive
 - file a bug which states that the current implementation is counterintuitive and work for the fix for 13.04 with the design team, security team and other related parties

2)
 - reject the patch and start working on the policykit permissions and dialog
 - requires FFe
 - needs input from the design team, security team and Thin Client

3)
 - reject the patch
 - leave this bug open

I would go with 1)

See the screenshot how the menu looks like when APs are insensitive and one AP has existing configuration.

I don't have a preference. (1) would be less obvious, but (2) would be less translated, since we're way past UI Freeze.

This does not appear to be a critical bug. For now, I think it should be option 3, leave it open. A non-invasive fix might be something that could be addressed post-release, but for between now and release, it's too late.

There would not be any issues with translations of such a dialog, since it's something that would come from policykit for which the strings should already be available and translated. It's just a matter of making sure the policy is set properly.

Regardless, option 3 is fine by me, but I strongly disagree that making items insensitive is the right way to fix this issue, it's more likely to introduce confusion ("why can't I click my wireless network?")

OK, let's go with 3) then. :)

quantal has seen the end of its life and is no longer receiving any updates. Marking the quantal task for this ticket as "Won't Fix".

raring has seen the end of its life and is no longer receiving any updates. Marking the raring task for this ticket as "Won't Fix".