I have an existing notification feed, but I'm looking at possibly migrating over to GetStream.
Currently, I'm using Laravel Notifications, to notify users and other objects.
I currently have something like the following:
1) Users
2) Groups
3) Group Members
So, when I CRUD a group, I simply notify all members of the group and also the group ($group->notifications returns a collection), which works fine.
Looking through the GetStream docs though, it seems there is a concept of 'followers'.
Does this mean, that all members of a group need to be followers of each other to see all notifications?
What about other objects, like, retrieving a feed for a Group? Do i need another Group Type in the dashboard to save activities to?
So, If I Person A and Person B are members of Group 1, When Person A saves Group 1, I'd like Person A, to see something like:
You saved Group 1
and Person B will see:
Person A saved Group 1
When I view the Group page, I'd like to pull in the activities that have happened to that Group.
Is this possible?
Thanks
Does this mean, that all members of a group need to be followers of each other to see all notifications?
Probably not. Stream allows you setup feed groups, following relationships, and use "targeting" to send activities to different feeds.
Based on the use case you described, you're probably best off with two Feed Groups, e.g. group and user_timeline. You can give each user their own user timeline feed and set it to follow other group feeds as appropriate.
When a user does something involving the group, an activity can be added to the group feed. This activity then propagates out to all users who follow the group.
What about other objects, like, retrieving a feed for a Group? Do i need another Group Type in the dashboard to save activities to?
You can always create multiple feed groups for a given app. The example with two groups is probably sufficient for your use case but you could go further with 3 groups...
user: User events posted to this feed. This feed will handle specific and non-group specific activities. If the activity relates to a group, the "to" field can be populated with the group feed name and this will cause the activities to be copied to that feed (and in turn propagated to it's followers).
user_timeline: Retrieved by users. Follows group feeds. User's may also follow another user's user_timeline feed in order to receive all events by that user (e.g. an asymmetrical follow like Twitter / or symmetrical follow like Facebook)
group: Receives user generated activities via the 'to' targetting. System/admin generated activities may also be add directly to the feed.
Related
after some time, I am still struggling to model my domain properly. Let me briefly introduce simplified background.
It is product monitoring SaaS. User needs to obtain a membership which defines his abilities and limits, let's call him a Member. Member can subscribe to products in order to keep track on product changes, and therefore being notified about it. Member can also create a group to which he can add subscribed products in order to customize notification behavior - "hey, in case of these products, notify me only if price drops more than 20%". Simply as that.
At first, I created three aggregates.
ProductAggregate
MembershipAggregate
GroupAggregate
Even though my use case is fairly simply, I can't figure what is a proper way of modeling that.
Member can subscribe to products. Does "subscribe" method belongs to Membership or Product aggregate? Membership can exist without subscriptions, so is Product.
Member can create group – I would say it belongs to GroupAggregate, but membership limits (i.e. member can create max. 3 groups) needs to be checked. Group has no idea about that, so we need to load membership aggregate to check if it is possible.
As you see above, both cases require knowledge about membership limits, so it would be natural to place it all in membership aggregate. On the other hand, pretty much every action in the system will depend on user membership limits and thus everything would have to go through that aggregate – which is obviously bad.
The only solution I came up with is to build membership with method like "canCreateGroup()" etc. and retrieve that aggregate in command handler (application layer). So CreateGroupCommandHandler would do:
Load membership aggregate, execute canCreateGroup
Load group aggregate, execute CreateGroup
However, this way everything related to membership would be checked in application layer (command handlers) and I believe it is a domain responsibility, so it would be wrong as well.
It appears that there's a requirement that no member ever breach their limits. In that case, every operation that could possibly breach the limits has to run through the membership aggregate. There's no way around that.
You can model the process of creating a group as its own process (with state, which enables resumption) in the domain, as in the saga pattern. For a given member ID and group ID, the create group saga:
attempts to add the group to the member's set of pending groups (the member validates that the group would not breach limits; note that this command has to be idempotent)
if that succeeds, records that the member has approved creation of the group
creates the group
if that succeeds, records that the group has been created
moves the group from the member's set of pending groups to the member's set of active groups
if that succeeds, record that the group creation process has completed
The reservation process means that the failure mode would be a group which never gets created stays in pending and eventually prevents a member from creating more groups. This situation can be detected by subscribing to the events from members (you seem to be event sourcing, judging from the tagging) and canceling (or perhaps resuming, depending on the interval) hung group creation attempts.
I am creating an application that should allow users to create or join a group with other users. Every user in a group will have access to some common information. The users are currently stored in a Postgres database with attributes: name and email. I am trying to create a model for groups that would contain a list of authorized users that can access its material.
One approach I thought of was creating a new table in the database consisting of rows of groups and each group had a column: 'authorized_users' which contained an array. However, I read that this is bad practice in SQL.
Another approach would be to create a new table each time a group is created and store the authorized users in that table.
I was looking for help to see if there is an API for node that already performs this, or if any of you have suggestions on how to implement this group model.
You need a new table that keeps the users in groups info, modelling a many to many relationship:
users_groups:
user_id,
group_id,
(optional) can_read, can_write, etc
i'm using the javascript getstream integration library: https://github.com/GetStream/stream-js.
I've configured a user feed on my getstream dashboard, suppose i add few users as user:test1 user:test2 user:test3. Is there any way that i can get list of all users that are registered on the user feed group.
Similarly i want this to work for news updates posted by user, where he can see list of users and can follow them.
It is currently not possible to list all the feeds created on a certain feed group via API. You are responsible to store the users of your application within your own backend.
I am working on a project in which a task needs to be assigned to users that potentially belong to two groups. For example - users which belong to Company A and also are User Type B. Is it possible to have two columns in the task list and require the workflow to assign the task only to users which are members of groups in both columns?
I don't think this can be achieved with OOTB approval workflow since you have to get intersection of users from both the groups. The simplest way will be create another group which will contain only users which belong to Company A and also are User Type B.
You can maintain this group manually or in SP2013 create a SPGroup User added event receiver which will automate this process.
http://www.c-sharpcorner.com/UploadFile/anavijai/create-groupuseradded-event-receiver-in-sharepoint-2013/
We have a Salesforce app where we have some custom objects and want to expose the various custom object rcords to customers.
We need to ensure that customers can see only the records belonging to their Account. Because of the way these records are setup(owned by various system users at different levels of processing), we cannot use owner based sharing...and cannot use criteria based sharing since its not dynamic(I cant use criteria based sharing to say "Share this record with all customer portal users who belong to the same Account as the record" at runtime).
So I know I have to use Apex based sharing. I have read up on the sharing objects and the sharing table. But how would I approach this.
I can write a trigger which upon inserting will create a share object and get all userids who belong to the customer portal group and whose account equals the account of the record and associate them with the share object of the record.
But I feel this is overkill correct? Lets say there are 5 users from one of our customers and lets say there are 500 records created a day...that means 2500 share objects a day just for 1 customer...for 10 customers this can go upto 25000...and scale in this way...
Am I right here?
Another problem would be if a new person joined that customer team..unless another process updates the sharing on older records, he/she cannot see the older records.
So is there a better/elegant way to do this? I thought of adding a share object to the group...but there is just one group "Customer portal group" and how do I associate the group with the account of the users?
I will appreciate any thoughts about this.
You should take a look at high-volume customer portal users. They're much cheaper relative to standard customer portal users and should meet your needs. Unlike regular users they have a totally different sharing concept. In a nutshell if they own an object they can see, if not they can't. You can then extend this based on whether a contact or account lookup on the object matches the logged in user.
Read up on this documentation:
License Types (scan to High Volume Customer Portal)
Granting High-Volume Portal Users Access to Records (login required)
You can use groups for sharing to avoid creating so many sharing records. You would have one group per account and one sharing record per account. Instead of managing thousands of sharing records you would have to manage hundreds of groups.
I haven't tried this approach with this many groups, but I read some time ago that it should work (someone posted using a LOT of groups for sharing). If you do try this, please tell us if it worked OK.