Skip to content

Loading…

Ideas for new features #82

Open
rubish opened this Issue · 8 comments

6 participants

@rubish

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/5095346

Sometimes 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.

@rubish rubish referenced this issue
Closed

Map-reduce support #61

@pokonski
Chaps member

Sometimes 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.

I like the idea :)

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.

This can be done basically by providing a different activity key to differentiate between reasons.

but providing support for custom fields and hooks to use them should suffice.

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.

@rubish

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.

This can be done basically by providing a different activity key to differentiate between reasons.

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.

@bismark64

I have an idea that can maybe be useful:
Enable custom triggers when is created a new Activity object, e.g: I have a Post model and I configure Public Activity to track when a Post model is created, updated or deleted. The basic idea would be implement some options in the "tracked" method:

include PublicActivity::Model
tracked, :after_create => my_custom_method_after_create, :after_update => my_custom_method_after_update,   :after_delete => my_custom_method_after_delete

Of course this can be translated to before triggers: before_create, before_update, etc.
This could be a nice feature to save some time and code to implement this triggers without have to hardcode creating custom activities.

@farnoy
Chaps member

Well, aggregation of custom attributes works exactly as you'd expect it to be, you pass a hash to tracked:

tracked params: {anything: :model_method, anything2: -> controller, model { controller.current_user.orders.count }}

Everything inside is evaluated against this method

@robertomiranda

I would like to see in this engine something with Sever Events Sent(Already included in Rails4) or Websockets :grin:

@mrryanjohnston

It would be nice to be able to set the :key attribute from the call to tracked similar to how we can pass owner and recipient.

@pokonski
Chaps member

@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 :)

@mrryanjohnston

@pokonski sure thing. I have a model that's namespaced, so the generated model_name ends up looking like my_rails_project_api_v1_my_model. Ideally, I'd like to overwrite this by doing something like:

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.