folks issueshttps://gitlab.gnome.org/GNOME/folks/-/issues2018-08-04T08:30:27Zhttps://gitlab.gnome.org/GNOME/folks/-/issues/28Refactor Individual property setters2018-08-04T08:30:27ZBugzillaRefactor Individual property setters## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#658326)](https://bugzilla.gnome.org/show_bug.cgi?id=658326)**
## Description
This doesn't have to be done for this cycle, since nobody seriously uses Individual ...## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#658326)](https://bugzilla.gnome.org/show_bug.cgi?id=658326)**
## Description
This doesn't have to be done for this cycle, since nobody seriously uses Individual property setters. However, it should still get done in the near future if possible.
From my e-mail of 2011-09-03:
• Individual property setters should write to all personas which have
the given property name in Persona.writeable-properties, but should
not create new personas (that's what
IndividualAggregator.ensure_individual_property_writeable() is
for).
- We document them as having synchronising behaviour which may or
may not be desirable. For Empathy's case, the behaviour will
actually be the same as it's always been, since we used to
(hackily) also write aliases and groups to stores which had
PersonaStore.is-writeable == false.
gnome-contacts doesn't care since it manipulates personas
directly. This is what we should advise any kind of non-trivial
client to do.
This works in all scenarios except scenario 3. I think the only
reasonable way to behave correctly in scenario 3 is for the client
to set properties of personas manually, as gnome-contacts does. I
can't think of a way to get Individual property setters to:
a. Reliably store properties such that they are consistently
returned by the Individual property getter afterwards.
b. Not create extraneous personas in the primary store.
c. Not shit all over persona stores like company LDAP which should
only be written to on special occasions.
i.e. This solution prioritises point a. and b. over point c.
Version: git masterFuturehttps://gitlab.gnome.org/GNOME/folks/-/issues/26Add a user avatar backend (like Gravatar or libravatar)2020-02-10T05:56:39ZBugzillaAdd a user avatar backend (like Gravatar or libravatar)## Submitted by nick richards `@nick.richards`
**[Link to original bug (#655116)](https://bugzilla.gnome.org/show_bug.cgi?id=655116)**
## Description
It would be great to have as many photos of contacts as possible, as such it would...## Submitted by nick richards `@nick.richards`
**[Link to original bug (#655116)](https://bugzilla.gnome.org/show_bug.cgi?id=655116)**
## Description
It would be great to have as many photos of contacts as possible, as such it would be awesome to have a gravatar backend to retrieve avatars of users based on a hash of their email address.
http://en.gravatar.com/site/implement/
We may think that this is better dealt with in a downstream project (such as libsocialweb) and just use a generic backend for there. If so, feel free to close and redirect.
Version: git master
### Depends on
* [Bug 660299](https://bugzilla.gnome.org/show_bug.cgi?id=660299)
### Blocking
* [Bug 791187](https://bugzilla.gnome.org/show_bug.cgi?id=791187)
### See also
* [Bug 774603](https://bugzilla.gnome.org/show_bug.cgi?id=774603)Futurehttps://gitlab.gnome.org/GNOME/folks/-/issues/25Ensure that FieldDetails are immutable to backends2018-08-04T08:28:30ZBugzillaEnsure that FieldDetails are immutable to backends## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#653233)](https://bugzilla.gnome.org/show_bug.cgi?id=653233)**
## Description
As discussed with Alex on IRC, we should ensure (and document) that backends can't m...## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#653233)](https://bugzilla.gnome.org/show_bug.cgi?id=653233)**
## Description
As discussed with Alex on IRC, we should ensure (and document) that backends can't modify FieldDetails instances. Instead, they should replace instances of FieldDetails they want to change with new instances, which have been deep copied and modified as appropriate.
This means that clients can safely modify FieldDetails instances that they're handed, and re-use them when updating properties without having to worry about breaking the internal state of a backend.
Version: git master
### Depends on
* [Bug 653679](https://bugzilla.gnome.org/show_bug.cgi?id=653679)
* [Bug 653680](https://bugzilla.gnome.org/show_bug.cgi?id=653680)
* [Bug 653682](https://bugzilla.gnome.org/show_bug.cgi?id=653682)Futurehttps://gitlab.gnome.org/GNOME/folks/-/issues/24Port Folks Telepathy test library to GDBus2019-02-13T08:41:22ZBugzillaPort Folks Telepathy test library to GDBus## Submitted by Travis Reitter
**[Link to original bug (#653198)](https://bugzilla.gnome.org/show_bug.cgi?id=653198)**
## Description
This is blocked by telepathy-glib being ported to GDBus (fdo#28782).
We've ported everything in F...## Submitted by Travis Reitter
**[Link to original bug (#653198)](https://bugzilla.gnome.org/show_bug.cgi?id=653198)**
## Description
This is blocked by telepathy-glib being ported to GDBus (fdo#28782).
We've ported everything in Folks that directly depended upon dbus-glib in bug #629716.
Version: git master
### Depends on
* [Bug 629716](https://bugzilla.gnome.org/show_bug.cgi?id=629716)
### Blocking
* [Bug 622871](https://bugzilla.gnome.org/show_bug.cgi?id=622871)
* [Bug 696177](https://bugzilla.gnome.org/show_bug.cgi?id=696177)
### See also
* https://bugs.freedesktop.org/show_bug.cgi?id=28782Futurehttps://gitlab.gnome.org/GNOME/folks/-/issues/20Add a gnome-keyring backend2018-08-04T08:27:21ZBugzillaAdd a gnome-keyring backend## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#652662)](https://bugzilla.gnome.org/show_bug.cgi?id=652662)**
## Description
Read-only view of the .gnupg keyring data (photos, name, e-mail address, comments, p...## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#652662)](https://bugzilla.gnome.org/show_bug.cgi?id=652662)**
## Description
Read-only view of the .gnupg keyring data (photos, name, e-mail address, comments, public key). Gives capabilities for encrypting to the person. Can expose the GPG key trust model (public keys have to be signed by someone else before you can trust them). Can be used to provide trusted linking information (by e-mail address) between personas.
Version: git masterFuturehttps://gitlab.gnome.org/GNOME/folks/-/issues/18add output to file to folks-inspect2018-08-04T08:26:50ZBugzillaadd output to file to folks-inspect## Submitted by Jeremy Whiting
**[Link to original bug (#651269)](https://bugzilla.gnome.org/show_bug.cgi?id=651269)**
## Description
It would be very nice to be able to dump folks-inspect output to a file, as sometimes the output i...## Submitted by Jeremy Whiting
**[Link to original bug (#651269)](https://bugzilla.gnome.org/show_bug.cgi?id=651269)**
## Description
It would be very nice to be able to dump folks-inspect output to a file, as sometimes the output is quite long. I tried with folks-inspect > file but got a segfault.
Version: git masterFuturehttps://gitlab.gnome.org/GNOME/folks/-/issues/15add support to find potential matches from folks-inspect2018-08-04T08:26:09ZBugzillaadd support to find potential matches from folks-inspect## Submitted by Raul Gutierrez Segales
**[Link to original bug (#647323)](https://bugzilla.gnome.org/show_bug.cgi?id=647323)**
## Description
Created attachment 185618
Add matches-all and matches-for to folks-inspect
The attached p...## Submitted by Raul Gutierrez Segales
**[Link to original bug (#647323)](https://bugzilla.gnome.org/show_bug.cgi?id=647323)**
## Description
Created attachment 185618
Add matches-all and matches-for to folks-inspect
The attached patch adds 2 commands to folks-inspect:
- matches-all (shows all matches among individuals)
- matches-for individual-id (show all match for a given individual)
**Patch 185618**, "Add matches-all and matches-for to folks-inspect":
[0001-folks-inspect-added-matches-all-and-matches-for-comm.patch](/uploads/f6e0294f6f5e1a7d0f8520e5a619b8ec/0001-folks-inspect-added-matches-all-and-matches-for-comm.patch)
Version: git masterFuturehttps://gitlab.gnome.org/GNOME/folks/-/issues/8Take advantage of requires() and ensures() pre- and post-conditions2018-08-04T08:24:52ZBugzillaTake advantage of requires() and ensures() pre- and post-conditions## Submitted by Travis Reitter
**[Link to original bug (#637897)](https://bugzilla.gnome.org/show_bug.cgi?id=637897)**
## Description
Vala has built-in support for function pre- and post-conditions. These should be helpful to make a...## Submitted by Travis Reitter
**[Link to original bug (#637897)](https://bugzilla.gnome.org/show_bug.cgi?id=637897)**
## Description
Vala has built-in support for function pre- and post-conditions. These should be helpful to make assumptions more explicit.
Version: git masterFuturehttps://gitlab.gnome.org/GNOME/folks/-/issues/7Enable fatal warnings for non-releases in libfolks-telepathy2018-08-04T08:24:42ZBugzillaEnable fatal warnings for non-releases in libfolks-telepathy## Submitted by Travis Reitter
**[Link to original bug (#630755)](https://bugzilla.gnome.org/show_bug.cgi?id=630755)**
## Description
We can't yet include --fatal-warnings for the Telepathy-based components because of fdo #28782
Th...## Submitted by Travis Reitter
**[Link to original bug (#630755)](https://bugzilla.gnome.org/show_bug.cgi?id=630755)**
## Description
We can't yet include --fatal-warnings for the Telepathy-based components because of fdo #28782
This affects libfolks-telepathy, libfolks-backend-telepathy, and the Telepathy test library.
Version: git master
### See also
* https://bugs.freedesktop.org/show_bug.cgi?id=28782Futurehttps://gitlab.gnome.org/GNOME/folks/-/issues/6Folks should auto-link Personas with corresponding fields2018-08-04T08:24:24ZBugzillaFolks should auto-link Personas with corresponding fields## Submitted by Travis Reitter
**[Link to original bug (#629538)](https://bugzilla.gnome.org/show_bug.cgi?id=629538)**
## Description
There are a lot of secondary fields on Personas that can suggest they are the same person (in whic...## Submitted by Travis Reitter
**[Link to original bug (#629538)](https://bugzilla.gnome.org/show_bug.cgi?id=629538)**
## Description
There are a lot of secondary fields on Personas that can suggest they are the same person (in which case, we'd like to auto-link them into the same Individual).
For example, an XMPP UID "foo@example.org" might also be an email address. If we have a Persona with a UID "foo@example.org", which is identified as an email address, we probably want to link these two Personas together.
Similarly, an IM-based Persona may have extended contact info that suggests another email address entirely. However, we'll need to carefully check the trust level of the backend(s) involved, since we must not allow contacts to maliciously cause auto-linking of themselves with another person's Personas, since that could allow them to spoof the other person's identity.
This depends upon bug #629537, so users can correct any flaws in this algorithm while awaiting bug fixes. (Not that we'd have any errors in our algorithm.)
Version: git master
### Depends on
* [Bug 629537](https://bugzilla.gnome.org/show_bug.cgi?id=629537)Futurehttps://gitlab.gnome.org/GNOME/folks/-/issues/5Add location awareness support2018-08-04T08:23:38ZBugzillaAdd location awareness support## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#627400)](https://bugzilla.gnome.org/show_bug.cgi?id=627400)**
## Description
We need a location interface, so that an Individual can easily expose the locations ...## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#627400)](https://bugzilla.gnome.org/show_bug.cgi?id=627400)**
## Description
We need a location interface, so that an Individual can easily expose the locations of all its Personas.
See location_update() in empathy-individual-widget.c.
Version: git master
### Blocking
* [Bug 658553](https://bugzilla.gnome.org/show_bug.cgi?id=658553)
* [Bug 676015](https://bugzilla.gnome.org/show_bug.cgi?id=676015)Future