-
Notifications
You must be signed in to change notification settings - Fork 803
expand pinned articles #6947
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
expand pinned articles #6947
Conversation
8ce3f18 to
e68ed07
Compare
e68ed07 to
6fddf8e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apart from the comment about the user, this looks good!
My main concern here is that we are going to have two distinct systems to handle featured articles which will make maintainability and readability a complicated task and it's prone to future bugs.
How about unifying the two systems? We could replace the pinned_articles in the AAQConfig with a FK to the PinnedArticlesConfig. That would also require to relax the DB constraints ofc on the config and maybe a small DB migration but the lift feels low compared to the benefits. Thoughts?
Great! I would prefer that as well! I'll do that. |
38e4bc0 to
47f0bd5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this looks good. My concern with this approach is that we are forcing the same pinned articles for the product landing page and the AAQ. Adding the pinned article config as a FK to the AAQConfig will allow for greater flexibility by having a different configuration file per page. Thoughts?
I don't see when we'd ever want different pinned articles on a product landing page versus its AAQ product page, so it feels like we're adding something that we might not ever use? I can add it though. |
The AAQ has a subset of topics compared to the product so I would assume that in most cases the AAQ will need to differentiate when we have the need to divert from the default behavior and have pinned articles |
27c43a6 to
9e11c8b
Compare
9e11c8b to
4323eb6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this looks good. My main comment is about migrating existing data and moving the FK to the AAQConfig instead.
84908c5 to
eca91a6
Compare
eca91a6 to
91f5122
Compare
91f5122 to
797bfc7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good 🚀 r+wc
mozilla/sumo#2562
Notes
PinnedArticleConfigmodel that defines pinned articles for use by the home page, the product-landing pages, and the AAQ product-landing pages.pinned_articlesfield within theAAQConfigmodel has been removed, and replaced by a foreign key to aPinnedArticleConfiginstance. I've added a data migration for any existing pinned articles associated withAAQConfiginstances, and of course, it's run prior to the removal of thepinned_articlesfield.PinnedArticleConfiginstance has been added to theProductmodel to specify pinned articles for that product's landing page.Pinned Article Configurationsunder theWIKIsection in the admin console.get_featured_articlesfunction. That function now takes into account the viewing user, and can deliver restricted articles if the user has the permission to see them.Screenshots