-
Notifications
You must be signed in to change notification settings - Fork 336
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
Ideas for new features #82
Comments
I like the idea :)
This can be done basically by providing a different activity key to differentiate between reasons.
We allow that, too, since 1.0.0 :) Thanks for the interesting ideas, I'd really love to extend the wiki with more custom examples like adding custom attributes, using workers etc. So I'd gladly take contributions to it. |
I very much like the p_a's way of handling the problem and would like to switch to p_a from our solution. However, it might take us some time to come back to refactoring the thing.
Yes, good suggestion, but I would still prefer a new attribute for the recipient association with the activity, to keep number of templates and translations in check. I went through the documentation, but didn't find anything related to custom attributes or hooks. If you can provide some basic example that would be really helpful. |
I have an idea that can maybe be useful:
Of course this can be translated to before triggers: before_create, before_update, etc. |
Well, aggregation of custom attributes works exactly as you'd expect it to be, you pass a hash to tracked params: {anything: :model_method, anything2: -> controller, model { controller.current_user.orders.count }} Everything inside is evaluated against this method |
I would like to see in this engine something with Sever Events Sent(Already included in Rails4) or Websockets 😁 |
It would be nice to be able to set the |
@mrryanjohnston thanks for the suggestion, can you show an example why that would be helpful to you? I'm trying to find valid use cases :) |
@pokonski sure thing. I have a model that's namespaced, so the generated module MyRailsProject::Api
class V1::MyModel
include PublicActivity::Model
tracked key: Proc.new { |controller, model| model.tracked_key(controller, model) }
def tracked_key(controller, model)
"#{model.class.name.demodulize}.#{controller.action_name}"
end
end
end |
I have been reading the docs and searching for an answer for 2 days now, and finally as I'm thinking of starting an issue @mrryanjohnston has already asked it. I also have namespaced models and have to write code like def trackable_clazz
if self.key.split('.').first == 'name_space_model_name'
Object.const_get 'NameSpace::ModelName'
... everytime I try to get the resource in an activity. Is there some kind of fix already to this? |
We did a similar implementation and following are the few things which can be added to public_activity. These can be moved to individual threads if they are planned to be added to public_activity.
I hope people using mongoid would be having many embedded documents like comments for posts. When someone creates a comment, activity should be able to handle trackable properly. We have shamelessly copied
doc#selector_from
from https://github.com/joeyAghion/delayed_job_shallow_mongoid/blob/master/lib/delayed/shallow_mongoid.rb#L36 and created a custom type around it to handle root and embedded documents seamlessly. ref: https://gist.github.com/rubish/5095346Sometimes the activity might go out to many recipients(100s for us) and creating individual entries for each recipient might add too much overhead to response time. We handle it by creating activity with multiple recipients initially and processing them via a delayed worker later. The worker creates activities for each recipient or aggregates them as required. We take care of showing the activities into user feed even if it is in its raw form yet. That way user gets updates of latest activities, irrespective of the load on the worker. However, it may create some confusion if the activity is later on aggregated into some other activity.
Users might also want to know, why are they seeing an activity in their feed? Like if they they created the post, commented on it or were tagged in it. It might be mot make sense for public_activity to handle all such use cases, but providing support for custom fields and hooks to use them should suffice. Custom fields can also help solve another use case of tracking engagement.
Custom fields can accommodate to a lot of other use cases, like distributing notifications on different channels, in app notifications, emails notifications and facebook notifications. Using fields for if notification for email is pending and when it was sent out can help in retrying any failed attempts. Also saving if the information about user visits from urls in notification can provide invaluable analytics on user behavior, like which channel is most effective, what is the response time of users on different channels, which notifications are not getting good response etc.
The text was updated successfully, but these errors were encountered: