Account.I.Storage has a property for a set of restriction flags. McdAccount::always-on allows the creation of accounts that can never go offline (ideal for telephony), but now that we've abolished Mcd* as a plugin API, there's no actual way to achieve that. On Bug #71384 I suggested: > > return TP_STORAGE_RESTRICTION_FLAG_CANNOT_SET_PARAMETERS | > > TP_STORAGE_RESTRICTION_FLAG_CANNOT_SET_ENABLED | > > TP_STORAGE_RESTRICTION_FLAG_CANNOT_SET_PRESENCE | > > TP_STORAGE_RESTRICTION_FLAG_CANNOT_SET_SERVICE; > > I think this suggests how we can supersede McdAccount::always-on: > > * if we CANNOT_SET_ENABLED, then Enabled is forcibly set to what the > storage backend says it is (instead of TRUE, as always-on does) > > * if we CANNOT_SET_PRESENCE, then AutomaticPresence and ConnectAutomatically > are forcibly set to what the storage backend says they are, > and RequestedPresence is forcibly set to > (ConnectAutomatically ? AutomaticPresence : (OFFLINE, "offline", ""))
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.