-
Notifications
You must be signed in to change notification settings - Fork 6
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
show pdf location restriction banner per file #2748
Conversation
…wnload for content not available
4c9f052
to
7e289bc
Compare
@@ -9,6 +9,7 @@ | |||
|
|||
<% component.with_authorization_messages do %> | |||
<%= render LoginComponent.new %> | |||
<%= render LocationRestrictionComponent.new %> |
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.
Could we combine LoginComponent and LocationRestrictionComponent and call it AuthMessages. Maybe we want to wait until this is in.
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.
We just talked and agreed we can wait on that change until later, but that sounds like a good idea for subsequent work.
// If the location restriction target is available, then trigger auth denied message. | ||
// The event will lead to the locked icon being displayed for this item | ||
// This allows the lock window to show | ||
const event = new CustomEvent('auth-denied', { accessService: accessService }) |
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 think we should stuff the location restricted message in this event. Then we can have a controller devoted to displaying these messages, and this controller would not have to deal with 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.
This can be a follow-on PR 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 think that approach makes sense and it would be fine to do in a follow up PR. @dnoneill and I were also discussing the other cases (embargo etc.) so it makes sense to have that logic in its own event/controller framework.
def available? | ||
document_resource_files.first&.downloadable? | ||
!document_resource_files.first&.no_download? |
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 still not clear on why we need this at all. Can't we just run this all through the IIIF auth?
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.
The PDF Component html will not show the viewer at all if the "viewer.available?" is false. Instead, it will just show a "content not available" section. This change ensures the content not available section is not displayed unless the first file is a "no download" option. If we want to change that logic, I'd suggest tackling that in a different issue because there is probably more to streamline here (or to work out).
Closes #2360
What this pull request does:
Note: This should work in staging, but the stacks changes will need to be pushed to production first for these embed changes to work in production