-
Notifications
You must be signed in to change notification settings - Fork 16
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
Remove specialist topic code from Publishing API #2669
Remove specialist topic code from Publishing API #2669
Conversation
6358da3
to
8e71410
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.
Appreciate this is only draft, but wanted to point out a few things before you got too far!
@@ -1,22 +1,21 @@ | |||
{ |
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.
d85bfbf is a big commit and hard to review. I've always been slightly confused by the difference between base_links and whitehall_edition_links. What do you think about splitting this commit:
- Remove topic from
base_links
, and runrake build_schemas
as per the docs. What I don't think that will do is update the examples so you'd have to add those to the commit manually. Perhaps by runningrake
and seeing which fail? - Remove topic from
whitehall_edition_links
and same as above.
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.
I will split it later before putting this PR as ready for review.
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.
I've separated dist files (they are autogenerated) from others, which should make it easier to review.
@@ -1020,12 +1020,6 @@ | |||
"type": "object", | |||
"additionalProperties": false, | |||
"properties": { | |||
"additional_topics": { |
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.
I'll come back to this, or have you already checked? Ie do you have anything that confirms these fields (additional_topics and primary_topics) are specialist topics?
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.
I've grepped through email apps and found nothing. If you know that it is used somewhere else, please, let me know.
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.
Also, we have contract tests, but if they cannot be relied on, please, let me know.
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.
I'm a bit confused by ddaf127 and 513f78f
It looks like we need to remove topics, additional_topics and primary topic from the tags attribute of the email alert schema. And the relevant examples need to be updated. But I'm struggling to figure out if the examples you've added are including this schema. If they are, then it might be that there's some additional code changes needed which would form part of this change.
So let's make this it's own PR. As yet I've not removed any code from email alert service or email alert api that might be using these fields. So hopefully the contract tests will fail in a helpful and informative way so we can link all the relevant work.
@unoduetre I know this is still a draft, and that you've previously said you want the schemas to reflect the state of the database and therefore not split the PR. But at 378 files and 11 commits-ish I really think this PR is too big to review or safely merge:
My suggestion: We could remove topics from whitehall_edition links in one PR, remove it from base_links in a second PR, remove additional_topics etc in a third. Is there something I'm missing here that makes that impossible? |
a73c7c6
to
1ec47ae
Compare
As discussed with @hannako, this PR need to be split into a number of separate PRs. |
I've added additional commits as I've found during review one more thing I missed earlier. |
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.
Thanks for such a thorough piece of investigation @unoduetre really amazing attention to detail!
I have obviously suggested a rework, but hopefully it will make things easier rather than more complicated. Am very happy to pair on any aspect.
# Taxons that have been created by merging old 'legacy' taxons will have | ||
# a reverse link to determine where the replacement Topic Taxonomy taxon | ||
# now resides | ||
"topic_taxonomy_taxons" => "frontend_links_with_base_path", |
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.
It sounds like topic_taxonomy_taxons
were to do with mapping specialist topics to taxonomy topics, so I think it's fair to assume that this field is no longer required. It also looks like this attribute isn't being used in the publishing apps or in the frontend apps anyhow 👍
So let's cherry pick bf0fa5f and b155257 into a fresh PR. Linking to that grep in the commit message/PR description, so that it's easy to review and merge with confidence that nothing will break.
@@ -69,17 +69,6 @@ | |||
"document_type": "organisation", | |||
"analytics_identifier": "D1198" | |||
} | |||
], |
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.
Let's cherry pick 234c0ee and 00f784c into its own work - "Remove specialist topics from whitehall_edition_links
and base_link
schemas, and update relevant schema examples."
I think the CI will fail until we've updated any code that looks for topics
in links. Eg breadcrumbs in the gem. In fact having this PR as its own piece of work will help us identify dependencies and give us a to do list of code to update.
@@ -37,7 +37,6 @@ | |||
email_alert_type: { | |||
type: "string", | |||
enum: [ | |||
"topics", |
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.
Let's cherry pick ad572f9 and 2a8893b into its own work: "Remove topics
from email_alert_signup schema and associated examples". I'm not sure we've removed this field from the publishing applications as per the documentation for removing-a-field-from-a-content-schema so it would be nice to have this as a standalone PR, so we can link to relevant changes in other apps.
@@ -1020,12 +1020,6 @@ | |||
"type": "object", | |||
"additionalProperties": false, | |||
"properties": { | |||
"additional_topics": { |
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.
I'm a bit confused by ddaf127 and 513f78f
It looks like we need to remove topics, additional_topics and primary topic from the tags attribute of the email alert schema. And the relevant examples need to be updated. But I'm struggling to figure out if the examples you've added are including this schema. If they are, then it might be that there's some additional code changes needed which would form part of this change.
So let's make this it's own PR. As yet I've not removed any code from email alert service or email alert api that might be using these fields. So hopefully the contract tests will fail in a helpful and informative way so we can link all the relevant work.
@@ -0,0 +1,43 @@ | |||
class DeleteSpecialistTopicsFromDatabase < ActiveRecord::Migration[7.1] |
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.
As mentioned previously - I think it's safer to have a standalone PR for the database migration. And I'd definitely want to chat this PR through with someone from Publishing Platform first.
This application is owned by the publishing platform team. Please let us know in #govuk-publishing-platform when you raise any PRs.
Follow these steps if you are doing a Rails upgrade.
What
When all specialist topic pages have been archived and redirected, we need to remove the specialist topic related code from Publishing API. This application is owned by Publishing Platform.
Why
To remove technical debt
Trello ticket