-
Notifications
You must be signed in to change notification settings - Fork 43
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
497 edit page related external links #2490
base: main
Are you sure you want to change the base?
Conversation
0e3c825
to
30a73c3
Compare
30a73c3
to
61b158b
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.
LGTM! Just one tiny comment
app/helpers/tabbed_nav_helper.rb
Outdated
@@ -23,6 +23,8 @@ def current_tab_name | |||
"unpublish" | |||
when "admin" | |||
"admin" | |||
when "related_external_links" | |||
"linking" |
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.
Might just be me but the name 'linking' seems a little different to the other tabs. Would 'external_links' be more in keeping with the other tab names and match up more with the name of the property in the Artefact model?
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.
Might just be me but the name 'linking' seems a little different to the other tabs. Would 'external_links' be more in keeping with the other tab names and match up more with the name of the property in the Artefact model?
Yeah that's been bugging me a bit since the start. I took the name from the routes file that appears to redirect related_external_links
in the URL to linking
in the views but I have no idea why. Happy to hear further opinions on that though.
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 guess we can use whatever we want here, as it's not really user-visible. So long as we make sure we update all the places that might reference it.
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 changed linking
to related_external_links
in all appropriate places. I think it reads better like that.
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.
When the external links are invalid, the invalid values are not persisted in the text boxes, the text boxes are simply populated with whatever the currently-saved external links are. This appears to be the existing behaviour…not sure whether we are happy to keep this behaviour for now?
@@ -4,6 +4,7 @@ $govuk-page-width: 1140px; | |||
@import 'govuk_publishing_components/govuk_frontend_support'; | |||
@import 'govuk_publishing_components/component_support'; | |||
@import 'govuk_publishing_components/components/button'; | |||
@import 'govuk_publishing_components/components/add-another'; |
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.
Very minor, but could we move this up a line to retain alphabetical ordering?
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.
That would make sense but I found that some styles for the gem-c-add-another__remove-button
class get over-written by the generic button
styles when they are in that order. That seems to explain the spacing issue you have noted elsewhere WRT the delete button as well. It does seem a little bit unsatisfactory though so I wonder if we should make a change to the component stylesheet to fix this because I should think it's bound to happen again somewhere else.
assert_equal "External links is invalid", flash[:danger] | ||
end | ||
|
||
should "update related external links and display a success message when succesfully saved" do |
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.
Typo in "succesfully".
}, | ||
} | ||
|
||
artefact.reload |
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.
artefact.reload |
I don't think this reload is required, since we're not checking the artefact (and we also wouldn't need the first line either then).
}, | ||
} | ||
|
||
artefact.reload |
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.
artefact.reload |
Same as above.
}, | ||
} | ||
|
||
artefact.reload |
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.
artefact.reload |
Same again.
flash[:danger] = artefact.errors.full_messages.join("\n") | ||
end | ||
else | ||
flash[:danger] = "There aren't any external related links yet" |
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 can't find a test for this branch?
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.
Hmm, yes, that's a good point. I've added a test but it might need more thinking about because that scenario never occurs with the new interface because it always presents the user with fields even if they are left blank (there's no equivalent to this in the legacy version). Maybe that whole branch isn't really necessary any more. This also relates to the problem of validating the two blank fields which currently doesn't happen but returns a success message even though nothing has changed. 🤔
end | ||
end | ||
|
||
without_javascript do |
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.
This breaks the pattern used elsewhere in the integration tests, where we usually inherit from either IntegrationTest
or JavascriptIntegrationTest
depending on whether we're testing with or without Javascript.
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.
Yes, wondered about that. I've added a new test file to test the JS scenarios within this test and removed them from here. As an aside it's worth noting that if we run the current tests inheriting from JavascriptIntegrationTest
then we get a few failures in its current state.
test/integration_test_helper.rb
Outdated
@@ -64,6 +64,26 @@ def filter_by_content_type(option, from: "Content type") | |||
end | |||
end | |||
|
|||
def with_javascript |
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 don't know we need (or want these). We already have a way to have integration tests with or without javascript (by inheriting from either IntegrationTest
or JavascriptIntegrationTest
)—I'm not sure we want to add a second way of doing this.
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.
Yes, after the change above I have reverted this. 👍
51e97e3
to
4baa904
Compare
Trello
This gives the user the ability to add/delete/edit external links to a document. It uses the Add another component, which provides a different UI in JavaScript and non-JavaScript scenarios (shown below).
One aspect of the Acceptance Criteria that is not covered so far is to display an error message when both the "Title" and "URL" fields are blank: it continues to follow the current behaviour of displaying a success message while not saving the changes. This proved problematic because in a non-JS scenario it is in fact acceptable to submit empty fields because these are always provided by the component and may not be used.