Fix: Subtract automatic project likes from daily stats

[Falciron]

Because

The daily metrics posted to the Odin Project's #top-daily-stats Discord channel are primarily meant to portray daily member activity. Since the single automatic project like granted upon project submission is performed by the system and not a human, it should be omitted from the count of projects liked.

This PR

• Modifies the project like count method within the daily summary notification service to subtract the number of projects submitted that the same day.

Issue

Related to #5300

Additional Information

Discord Discussion

Pull Request Requirements

• I have thoroughly read and understand The Odin Project Contributing Guide
• The title of this PR follows the keyword: brief description of change format, using one of the following keywords:
  • Feature - adds new or amends existing user-facing behavior
  • Chore - changes that have no user-facing value, refactors, dependency bumps, etc
  • Fix - bug fixes
• The Because section summarizes the reason for this PR
• The This PR section has a bullet point list describing the changes in this PR
• I have verified all tests and linters pass after making these changes.
• If this PR addresses an open issue, it is linked in the Issue section
• If applicable, this PR includes new or updated automated tests

[KevinMulhern]

Nice spot with this @Falciron! this was definitely something we overlooked.

Although we'd probably be ok with assuming a 1:1 relationship between submissions and auto-likes, it's not a given. People can unlike their submission, or future maintainers might remove the auto-like feature etc. Then the count could become wrong again silently.

Theres also a potential for negative counts. For example, if 20 projects are submitted and 5 of those learners unliked their submission for whatever reason the formula would be: 15 likes - 20 project submissions.

To make this more robust, I think we should filter out the auto likes at a query level to have the organic like count. I think the approach might be to mark the appropriate likes as auto-liked with a flag:

1. Add an auto_liked flag column to the likes table
2. Set the auto_liked value to true when we create the auto like - we should be able pass it through to our like method and set it there.
3. Use a scope like not_auto_liked to filter the Likes when counting them in the daily summary.
4. Backfilling auto_liked on our legacy like records would be nice too, but that could be left for a separate story.

[Falciron]

You raise excellent points, and I think you're especially wise to run the count off of filtered data itself rather than make another short-sighted correction. Do you see the system user changing ID, that we'd need the auto-like to be more than just a generated column? (And if it doesn't change ID, do we need the extra column at all?)

It may take me a little longer to design and implement the correct fix, as I'm still early on in the Ruby path. That said, I can see exactly which table column we'd need for the filter, so it gives me some hope I could figure it out. I'll give it a few days and if I can't figure it out, I'll report back and release the issue if needed.

[KevinMulhern]

Thanks @Falciron - no rush, and feel free to ping me with any questions!

Do you see the system user changing ID, that we'd need the auto-like to be more than just a generated column? (And if it doesn't change ID, do we need the extra column at all?)

We don't have a single system user; we just programmatically have users like their own projects upon submission. Because the user_id varies, filtering isn't straightforward sadly.

We could derive them with a join (like.user_id == project_submission.user_id), but I think setting a boolean flag at creation would be cleaner. It makes the "auto-like" an explicit domain concept and keeps the logic much simpler than relying on data relationships.