🐛 fix missing type field in some posts_gdocs rows #3046
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With the introduction of data-insights, the
typefield of the content json blob became more important to the point where the admin refuses to show the content of a gdoc that does not have this field set. Most gdocs had it set in the db already but some only had it in the gdoc document. The admin now breaks if the type is missing which leads to a bind since if the DB does not already have the type set, there is no way for the user to get it set.This PR just assigns the type
articleto all (12 or so) posts_gdocs that do not have the type set. Even if the page is actually a topic page, the next time it is opened in the admin, the correct type will overwrite the field in the db. I checked that none of the 12 documents that will be influenced by this are currently published AND are non-articles, so this should not break anything in baking either (i.e. there are no published topic-page entries or similar that would be wrongly baked as articles)