| Summary: | add API for accounts that cannot be disabled | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Simon McVittie <smcv> |
| Component: | mission-control | Assignee: | Simon McVittie <smcv> |
| Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | enhancement | ||
| Priority: | medium | CC: | john.brooks, xclaesse |
| Version: | git master | Keywords: | patch |
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | review? | ||
| i915 platform: | i915 features: | ||
| Attachments: |
[1/2] fakeaccountsservice: be a bit more object-oriented
[2/2] Replace McdAccount::always-on with the existing TpStorageRestrictionFlags [3/3] Allow backends, but not D-Bus clients, to delete restricted accounts Fix addition of restrictions to test accounts |
||
|
Description
Simon McVittie
2013-11-08 14:17:55 UTC
Created attachment 88898 [details] [review] [1/2] fakeaccountsservice: be a bit more object-oriented Created attachment 88899 [details] [review] [2/2] Replace McdAccount::always-on with the existing TpStorageRestrictionFlags I used CANNOT_SET_PRESENCE to control access to ConnectAutomatically as well as the obvious AutomaticPresence and RequestedPresence, because RequestedPresence is not under the storage plugin's control - it is derived from ConnectAutomatically and AutomaticPresence at runtime. Use MCD_DBUS_PROP_SET_FLAG_ALREADY_IN_STORAGE as a way to bypass the storage restriction flags, so that storage plugins themselves can alter enabledness etc. even if they don't allow MC to change it. The regression test for this initially failed, because toggled_cb() did not pass that flag to the McdAccount: fix that too. We should probably have a restriction flag for the ability to delete accounts, too. Not implementing that right now in case it interferes with Bug #71384, and because it requires telepathy-spec work. At the moment, mcd_account_delete() disables the account, which means if you can't disable an account, you also can't delete it (probably good); it also means that the 'deleted' signal from the storage plugin can't delete it either (bad). Created attachment 88900 [details] [review] [3/3] Allow backends, but not D-Bus clients, to delete restricted accounts I assumed that if TP_STORAGE_RESTRICTION_FLAG_CANNOT_SET_ENABLED or TP_STORAGE_RESTRICTION_FLAG_CANNOT_SET_PRESENCE, then a hypothetical CANNOT_DELETE flag would also have been present. I like this, makes much more sense! +1 Pushed those 3 patches for you to master, because I have changes depending on them. Thanks. For our future selves' benefit: fixed in git for 5.17.0 Created attachment 89158 [details] [review] Fix addition of restrictions to test accounts --- Xavier, this might fix the test failures you were seeing? +1 Fixed again, 5.17.0. Sorry about that. More patches to come on Bug #71390, reinstating some of the stuff I reverted. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.