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

Ideas for new features #82

Open
rubish opened this issue Mar 6, 2013 · 9 comments
Open

Ideas for new features #82

rubish opened this issue Mar 6, 2013 · 9 comments

Comments

@rubish
Copy link

rubish commented Mar 6, 2013

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.

@pokonski
Copy link
Member

pokonski commented Mar 6, 2013

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

rubish commented Mar 6, 2013

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

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

farnoy commented Mar 15, 2013

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

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

@mrryanjohnston
Copy link

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

pokonski commented Nov 2, 2015

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

@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

@rendekarf
Copy link

rendekarf commented Jul 18, 2016

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?

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

No branches or pull requests

7 participants