search

ibm-watson-data-lab / advocated-old

Developer Advocacy/Evangelism activity recording utility
1 stars 0 forks source link

Associate Events #30

Open bradley-holt opened 8 years ago

bradley-holt commented 8 years ago

It would be ideal if we could have a way to associate individual event entries that are actually the same event (only within a team, see #28) in a way that still respects the autonomy of individual users entering data. This design of this feature needs to be discussed.

glynnbird commented 8 years ago

This is a tricky one. Each user's data exists in the same Cloudant database (server side) but each user only has visibility of their own data. It would be very fruity indeed to do some linkage server side.

bradley-holt commented 8 years ago

Ultimately what we need here is the ability for each user to see and select from list of events which have been entered by their fellow group members. Does Cloudant Envoy allow for read only permissions on a document? If so, we could:

  1. Have a process which reads the changes feed looking for new events.
  2. When a new event is found, this event is added to an "group events" document that contains a list of all events (and associated _id) for a group.
  3. All users in the group are given read only permission to this document (still need to sort exactly how "groups" are implemented, see #28).
  4. When creating or updating an event, a user may optionally select from an existing event. Note that I think it's important to allow the user to associate their event with an existing event while still entering a different event name (we can discuss the UI for this separately).
glynnbird commented 8 years ago

Envoy strictly segments the database into per-user slots, so no data sharing. Even if there was data sharing (somehow), the offline-first nature of the beast is that you'd get two folks creating the same event separately etc.

bradley-holt commented 8 years ago

What we'd probably need, then, is a document-per-user which lists all events that have been recorded for that user's group (along with associated _id values). This would require a system (similar to what I described above) that would read the changes feed, look for new events, and populate these per-user documents. Might this be workable?