feat: activity notifications

[lastcanal]

This feature adds activity notifications and optional change tracking to the app. It works by creating a 'abstract' activities table for each table we want activities to be associated with, as described here. I have added an activity table for almost every table in the database, although some some might no make sense and can be removed later.

The main entry point for adding activities is through Algora.Repo.insert/update/delete_with_activity. It creates an Ecto.Multi transaction for inserting associated activities and any Oban jobs. A more ergonomic option not requiring a Multi transaction is Activity.put_activity/3, but that requires adding a new on_remove: :ignore option to Ecto, otherwise we will have to load all associated activities for the target object prior to updating. I have removed this fork of Ecto for now and we are still using the default on_remove: :raise, as I am not not sure if they will adopt :ignore.

Querying this setup is accomplished by "unioning" all the tables that you want activities from, instead of filtering out the uninteresting assoc_type as you would with one giant 'activities' table. It also makes it possible to "union" across tables using associations, for example, getting all contract activities for a user. This even works with nested associations, for example getting all contract activities for a user, including associated transaction activities. Querying for all activities of one type is very simple.

My plan is to have all a user's 'activities' displayed in a 'feed' somewhere, and also emailed to them if they are not online, depending on the activity.

See this graph for a basic visual description:

graph
     TargetChangeset --> |Multi.new| InsertWithActivity
    InsertWithActivity --> InsertTarget
    InsertActivity --> InsertNotifierJob
    InsertWithActivity --> |with target changes| InsertActivity
    InsertTarget --> |with target id| InsertActivity
    InsertNotifierJob --> | Multi.transaction| NotifierJob
    NotifierJob --> |online| LiveUpdate
    NotifierJob --> |offline / forced| SendNotification
    SendNotification --> SendEmailJob
    SendNotification --> SendSNSJob

  

Loading

[lastcanal]

I have also added ExCoveralls and started building out some coverage; I am hoping to have all the notifications covered as some of them are tough to exercise. I've copied some of the mocks into test/support/mock for use in other tests.

[lastcanal]

Frustratingly, it seems as though it's impossible with this setup to load the "associated" object from the Activity without adding either a assoc_type field and suffering N+1, or having to use many_to_many relationships with every associated object in a join table. Ecto appears to be not as good at polymorphism as Ruby's ActiveRecord: https://elixirforum.com/t/multiple-polymorphic-associations-in-ecto/983/5

Would it be possible for you guys to give me a list of "Activities" you are interested in displaying to the user? I kept this implementation very broad because it would give me flexibility while figuring that out. Now that a join table with a foreign key per association is needed, it's probably best to figure out what we want ahead of time.

@zcesur you mentioned this was more granular than you would have done it; what level of granularity are you looking for? Also, it might be helpful to get me a list of all the emails that are sent from the old code base, along with their content.

FYI The reason Ecto doesn't do Rails style polymorphism is because it's unable to retain referential integrity on delete when using assoc_type and assoc_id on one big activities table. I'm going to send a PR to Ecto in the coming weeks, clarifying their documentation and providing the drawbacks to using their 'second approach' to polymorphism. It seems as though Ash is able to handle polymorphic unioning, perhaps the team at Ecto can help me figure out how to add something like has_one :assoc union: [table1, ...], but that will take some time that I don't think we have right now.

[zcesur]

That's a bummer, this looked very promising. What kind of error/result is your union_all reducer returning? While it's all fresh in your mind, I suggest writing up a quick question about it on the Elixir Forum before ditching it - I see lots of active senior Elixir folks there including the core Ash devs

In any case, the many-to-many approach should be perfectly fine!

In terms of granularity we'd probably wanna track most changes on most schemas at some point to have a proper audit log, but for the time being let's focus on main business capabilities & events, starting with things like:

• bounty.awarded
• bounty.posted
• bounty.repriced
• claim.submitted
• claim.approved
• tip.awarded

Let's do emails only for {bounty,tip}.awarded and bounty.posted for now - the former sent immediately and the latter sent as a digest once every N days based on user preference. Basic copy without any fluff or fancy formatting, e.g.

Subject: 🎉 $75 bounty awarded by ZIO

Congratulations, you've been awarded a bounty by ZIO! [View balance]

© 2025 Algora, Public Benefit Corporation
You are subscribed to Bounty awarded emails. Manage your communication preferences here.

[lastcanal]

All is not lost: I managed to get the associations loading using a virtual assoc_type field on Activity and a N+1 query. It's pretty un-optimized right now but can be made N+1 where N is the number of distinct 'activity tables' you need to access, which will only be 3 at most, at first. This think this might be possible to do in one query, but it would need to be done in Ecto as there is no way to configure a has_one association that is polymorphic.

Thanks for the extra info! I'm starting to get the hang of this app, should be easy to get those in there.

[zcesur]

Amazing 🫡