Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Associate Events #30

Open
bradley-holt opened this issue Jul 29, 2016 · 4 comments
Open

Associate Events #30

bradley-holt opened this issue Jul 29, 2016 · 4 comments

Comments

@bradley-holt
Copy link

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
Copy link
Contributor

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
Copy link
Author

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 Add a Concept of a Team #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
Copy link
Contributor

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
Copy link
Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants