Add Newsfeed

[frcroth]

Close #479

TODO

• [x] When logged in as student and going to the "/" page, redirect to the feed
• [x] Automatically write to feed on release. See https://github.com/frcroth/myHPI/actions/runs/7907525385/job/21584753770 for this. Obviously I couldn't test this properly (also the first time this will fail because the feed will only be deployed after the release is published).
• [x] Create tests
• [x] Add feed to setup test data
• [x] Pagination
• [x] Render html properly in snippet
• [x] Properly break snippet so that no html tag is unclosed
• [x] Translations
• [x] Ensure everything looks fine for mobile
• [x] Position pagination buttons better

Optional todos (can also be followups)

• [ ] Rss feed
• [x] Icons for post accounts (Fsr logo for fsr posts)
• [ ] Non-optional but not really part of this PR: The thing that posts the FSR mails
• [ ] Reactions on posts?

Questions

• how exactly should the redirect behavior work. Always redirect when clicking on "myhpi"? Redirect only when logging in and no next is set?

• @jeriox we can do the election release first and merge this afterward if there were no problems

[dasGoogle]

As an idea on how to handle this on the main page: Provide the first 3-4 news items (I think we could go for a two-column layout there and maybe even make the design a bit more compact) and add a link to "Further News" or similar.

[lukasrad02]

Regarding the Automatically write to feed on release feature: Do you think it would make sense to integrate this into the myHPI source code instead of the GitHub pipeline? I would think about some logic that checks the current version on startup, compares it with the version from the last startup and fetches the release description from GitHub if the version has changed.

I would prefer this over creating the post from the pipeline, as there are usually a couple of hours or days between the release on GitHub and deploying it in production. Having some large post advertising new features on the homepage although these features are not even available might confuse users.

[frcroth]

Your reasoning makes sense to me. I wonder how that could be implemented. Especially, it is not guaranteed that there are not two releases between restarting myHPI.

So basically, on start:

1. Check github for releases
2. Diff that list with some stored version (I think this may be tricky)
3. Create posts for all new releases (Since this does not need to use the POST route, we can also set the releases date as the post date)

I'm not sure how to do the diffing. We could of course just do this by title or something like that, seems a little flaky as both github releases and news feed posts are not guaranteed to keep their title. Otherwise another structure would need to be created to store the mapping of release to post for diffing purposes.

[lukasrad02]

You've got a good point. I was thinking about comparing the version numbers, but this would of course require us to store them in addition to the posts, like the separate structure you've mentioned.

I don't have a strong opinion on whether to introduce such a structure or not, but am slightly in favor of doing this. Otherwise, we would even have to differentiate between release posts and other posts during diffing, so there will be a lot of edge cases to consider.

[dasGoogle]

As another Idea: Why don't we pull the releases from GitHub in the action and place it in a file in the docker container? We could then simply parse that file on startup and mix it into the existing newsfeed without persisting anything in the DB.

[jeriox]

I think all of your variants are quite complex. I would prefer just using the tag of the current version (which we have easy acccess to from the python code) and creating a post for that by pulling the corresponding release notes if it does not exist yet.

[lukasrad02]

From my perspective, both the suggestions from Aaron and Julian would be fine

[frcroth]

Now implemented @jeriox 's version. the only problem I see here is that some releases may not be published. I.e.

• New version 2.0 is published with many cool features.
• A bug is found immediately after publishing (or while deploying)
• Version 2.0.1 is published with one fix.
• It deploys successfully, and only the 2.0.1 post is published.

To fix this, an admin needs to manually publish the post with python manage.py publish_release_post v2.0.0

Coming back to how the user is presented the feed. What I like about the current version is that no changes are done to core. I am not sure if that would be possible when including the posts on the root page. If that is not relevant, I think it should be possible.

[lukasrad02]

To fix this, an admin needs to manually publish the post with python manage.py publish_release_post v2.0.0

Nice solution!

Coming back to how the user is presented the feed. What I like about the current version is that no changes are done to core. I am not sure if that would be possible when including the posts on the root page. If that is not relevant, I think it should be possible.

Added some comment on this to the discussion above.