Skip to content
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

Update VisibilityTranslator to handle various edge cases #2089

Merged
merged 1 commit into from
Feb 25, 2021

Conversation

mark-dce
Copy link
Contributor

@mark-dce mark-dce commented Feb 24, 2021

Addresses the issue described in #2065

  • Treat embargo_length == nil the same as embargo_length == "None"
  • Restrict works with conflicting embargo settings - i.e. embargo_length == "6 months"
    BUT files_embargoed == toc_embargoed == abstract_embargoed == false
  • Add logger warnings and errors to trace unexpected states

BEFORE
image
image

AFTER
image
image

* Treat `embargo_length == nil` the same as `embargo_length == "None"`
* Restrict works with conflicting embargo settings - i.e. `embargo_length != "None"`
   AND `files_embargoed == toc_embargoed == abstract_embargoed == false`
* Add logger warnings and errors to trace unexpected states
@coveralls
Copy link

coveralls commented Feb 24, 2021

Coverage Status

Coverage increased (+0.05%) to 87.652% when pulling 6450ef7 on visibility_fixes into 0f6b7f9 on master.

@fnibbit fnibbit merged commit 1e8919a into master Feb 25, 2021
@fnibbit fnibbit deleted the visibility_fixes branch February 25, 2021 14:51
@@ -44,10 +45,14 @@ def self.visibility(obj:)
# When checking whether a value is true, check whether it has a "true" string too.
def visibility
return proxy.visibility if obj.hidden? || !obj.under_embargo?

return OPEN if embargo_length_none?(obj)
return ALL_EMBARGOED if obj.abstract_embargoed.to_s == "true"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder why this has to be forced to a string and compared to a string, rather than being a boolean? Don't know if it's relevant to the weirdness we're having, but it makes me curious.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's legacy data migrated that has string values while the new application uses booleans, so the field might have either "true" or 'true stored in Fedora.

I would have preferred to normalize the data at the time of migration, but that's not the choice the team made at the time.

I think we could consider doing that normalization now - I think it would make the data and the code simpler and easier to understand.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants