{"action":"opened","issue":{"url":"https://api.github.com/repos/amitaibu/og/issues/264","repository_url":"https://api.github.com/repos/amitaibu/og","labels_url":"https://api.github.com/repos/amitaibu/og/issues/264/labels{/name}","comments_url":"https://api.github.com/repos/amitaibu/og/issues/264/comments","events_url":"https://api.github.com/repos/amitaibu/og/issues/264/events","html_url":"https://github.com/amitaibu/og/issues/264","id":167255604,"number":264,"title":"Remove audience fields from users","user":{"login":"amitaibu","id":125707,"avatar_url":"https://avatars.githubusercontent.com/u/125707?v=3","gravatar_id":"","url":"https://api.github.com/users/amitaibu","html_url":"https://github.com/amitaibu","followers_url":"https://api.github.com/users/amitaibu/followers","following_url":"https://api.github.com/users/amitaibu/following{/other_user}","gists_url":"https://api.github.com/users/amitaibu/gists{/gist_id}","starred_url":"https://api.github.com/users/amitaibu/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/amitaibu/subscriptions","organizations_url":"https://api.github.com/users/amitaibu/orgs","repos_url":"https://api.github.com/users/amitaibu/repos","events_url":"https://api.github.com/users/amitaibu/events{/privacy}","received_events_url":"https://api.github.com/users/amitaibu/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-07-24T21:32:11Z","updated_at":"2016-07-24T21:32:11Z","closed_at":null,"body":"I'm still chewing on this idea, but here are some initial thoughts:\r\n\r\n## OG7\r\n* We have `OgMembership` all over the place, both for group content and users. \r\n* We have the idea that the field API will dictate what is allowed and what is not. That is, by specifying if the field is required or the field cardinality we would control how many `OgMembersihps` a user can have and of which type.\r\n\r\n## OG8\r\n\r\nWe already make a better distinction, and a `user` is a special case and `OgMembership` applies only to it. This already makes the API more predictable. Developers will still use good old entity reference for associating group content (i.e. non-user entities) to groups.\r\n\r\nHowever, we currently still have this mix in users, where you _could_ use `OgMembership` directly _or_ work via the user's audience field a la Entity-reference.\r\n\r\nHowever this duplication adds a lot of code to OG. And I'm not sure that having field API dictate the logic is still the right way.  Furthermore, controlling the business logic of how many/ which type memberships can be created for a user, can be achieved without having the logic inside the field API.\r\n\r\n## Summary\r\n\r\nCompletely remove the Audience fields for users. It will remain only for a group content, as a special case of an Entity reference field -- just so we could easily find content that is related to group.\r\n\r\nFor users, our API will only deal directly with the `OgMembership` entity. We could fairly easily add a UI that will allow group admins to add more groups to a user, without opting to field API.\r\n\r\nI believe this change will result with:\r\n\r\n* A cleaner and more predictable API\r\n* Less code"}}
{"actor":{"display_login":"amitaibu"}}