Foundation.mozilla.org: Add "review date" to PNI product model

[alanmoo]

So that we can filter by products reviewed in different months/years in the guide, we should add a field to the model allowing us to indicate review month and year. I don't have a particular opinion on format (string vs an actual date), so I'll leave it to the implementer to decide.

[beccaklam]

@alanmoo and team:

@xmatthewx mentioned a simple solution for this where on category pages we can show all the reviews (old and new) but on the homepage we just show the most recent stuff. More of Matthew's thoughts for context:

• As time passes we need to tell users if a review is fresh and relevant.
• We could display it as Month and Year since we don’t have daily activity.
• When a review is updated more than a trivial typo correction, date should be updated.
• Open question: does it need the word Review or Updated before the date. Or is the data by itself enough?
• Homepage view could be coded to only show reviews from the past X-months. (If we set 6 months to demote v-day, we should mark our calendars for 6 months after this years products land so our homepage doesn’t go blank.
• If a particular product feels too dated and should never be discovered, an editor can unpublish. Page can 404 or we could set up a forward to the homepage.
• Category views could still show all items for now. In the future, we could limit to X-number most recent, add search and/or a View More button at the bottom of these reviews.

Basically Jen doesn't want us highlighting old reviews but said a user should be able to find an old review. So without building out filter functionality on PNI, Matthew's solution seems to get at both those goals.

[xmatthewx]

string vs an actual date

The date should be a date, not a string, to enable sorting and filtering later.

And, we should allow author to select the date, rather than automate it. This allows us to fix a typo on a review from last year, without suggesting to readers that we've reconfirmed all the technical details this year.

[mmmavis]

Is this review date going to be a required or optional field?

[alanmoo]

My instinct is to make it required, and add a default of November 2018. Then we'll have to manually change the Valentine's items but that's not too many.

[mmmavis]

All year, month, and day are required arguments for Python's date object type, so I'm making November 1, 2018 as the default. If we really wanna have just year and month we could use tuple instead of date but I think it's less straightforward and will increase complexity in the future when we implement features like sorting and filtering.

[alanmoo]

Good, though how about November 2018 instead so that products that exist get that date? Then another migration so new ones get the current date?

[mmmavis]

@alanmoo

Good, though how about November 2018 instead so that products that exist get that date? Then another migration so new ones get the current date?

Does this require landing the PR to prod first (with default review date November 1, 2018) & filing a follow-up PR to change the default to current date? If so, I'll file a separate ticket.

[Pomax]

No, you just need two migrations: one that sets a default date, so when it runs, all existing records get updated, and then a second migration where it swaps the field to "now". We did the same thing in network-pulse-api here: https://github.com/mozilla/network-pulse-api/commit/37b9f0d1cde8f8262ff54a1cba0b0ef62b41b928