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

Mount Oaisys inside Jupiter [ch109] #1361

Conversation

ConnorSheremeta
Copy link
Contributor

Added scopes, inflection, config for oaisys, and mounted the engine to the route.

@ConnorSheremeta
Copy link
Contributor Author

CI should pass once ualbertalib/oaisys#17 goes through and is referenced in this Gemfile

@@ -9,6 +9,7 @@ class Thesis < JupiterCore::Doiable
has_many_attached :files, dependent: false

scope :public_items, -> { where(visibility: JupiterCore::VISIBILITY_PUBLIC) }
scope :belongs_to_set, ->(set) { where('member_of_paths::text LIKE ?', "%#{set}%") }
Copy link
Contributor

Choose a reason for hiding this comment

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

Just so we're consistent in our terminology (which is only going to get worse in phase 2 as the Community & Collection nesting gets joined by other nested relationships), let's use 'path' instead of set.

Also maybe throw a TODO on this so that once we've upgraded to Postgres 12 we come back and upgrade this query to use proper JSON operators instead of this terrible trick I came up with of casting the field to text.

# with an upgraded version of Postgresql this could be done more cleanly and performanetly
scope :belongs_to_path, ->(path) { where('member_of_paths::text LIKE ?', "%#{path}%") }
scope :record_created_from, ->(date) { where('record_created_at >= ?', date) }
scope :record_created_until, ->(date) { where('record_created_at <= ?', date) }
Copy link
Contributor

Choose a reason for hiding this comment

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

Really tiny nit, but I think these names are slightly confusing? Or at least I feel like I have to stop and think about what from and until mean, and that I'd misinterpret the behaviour and maybe be surprised by the "up to and including" nature of the queries.

Maybe something like created_on_or_before(date) and created_on_or_after(date)? Just so it reads fluently and there's no confusion as to what something like Item.created_on_or_before(date) returns when they start being used in non-OAI contexts (where there's going to be less awareness of what from and until mean in the OAI API context)

mbarnett
mbarnett previously approved these changes Nov 28, 2019
Copy link
Contributor

@mbarnett mbarnett left a comment

Choose a reason for hiding this comment

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

It's good

@ConnorSheremeta
Copy link
Contributor Author

Some comments on my second to last commit... from the other oaisys PR:

Found some exceptions thrown regarding unpermitted parameters when running tests.

When hitting /search with the header (Content-Type: application/json) or when running get search_url, as: :json (which the test does.) the exception is thrown (ActionController::UnpermittedParameters: found unpermitted parameter: :search ). The search param is present but it is an empty hash which is the reason the exception is thrown ("search"=>{}). One way to fix is is just supplying empty an empty string as a search parameter get search_url, as: :json, params: { search: '' } I am unsure as to why this happens when requesting a json response but I don't think that is done other than in tests?

I also found tests failing regarding draft theses... found unpermitted parameters: :date_created(3i), :date_created(2i) happens when trying to move to step two of the wizard for a thesis. Those parameters are created on line 56 and 58 of draft_actions.rb and are not in the permitted_attributes array in draft_thesis_policy.rb. I've added a check for @draft.is_a?(DraftItem) before setting the month and day automatically because date_created doesn't pertain to theses.

I think these are appropriate fixes, we could still revert to checking the parameters manually if you think there could be too many complications, but I think they're all cleared up.

@ConnorSheremeta
Copy link
Contributor Author

Found an issue from doing config.action_controller.action_on_unpermitted_parameters = :raise... if the page is changed an exception is thrown as :page is not a permitted param on line 3 of search helper. I've made it permitted and added an .except(:page) which should not change anything as the default behaviour was to just filter the unpermitted parameters anyways

@ConnorSheremeta ConnorSheremeta force-pushed the sheremet/ch109/mount-oaisys-inside-jupiter branch from a75d9be to e85b97a Compare December 13, 2019 17:22
# testing whether a value is in a json array, which newer version of Postgresql have.
#
# with an upgraded version of Postgresql this could be done more cleanly and performanetly
scope :belongs_to_path, ->(path) { where('member_of_paths::text LIKE ?', "%#{path}%") }
Copy link
Contributor

Choose a reason for hiding this comment

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

Very minor, just curious if we should worry about case sensitivity here? e.g use ILIKE instead of LIKE?

Maybe doesn't matter here?

Copy link
Contributor

Choose a reason for hiding this comment

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

Good question...

You could make the argument that case-insensitivity would be cleaner/work if someone manually typed a URL with all-caps. This is all just a terrible hack to work around the fact that the version of Postgres in Prod is currently 9.2 and 9.2 doesn't really support proper JSON queries that would let us ask whether that string is in the member_of_paths array. We're now building a new Production environment with Postgresql 12 that supports the proper query syntax, so this should just be switched to use the proper query instead.

I'll create a ticket/ quick PR to upgrade this query.

@@ -39,5 +39,8 @@ class Application < Rails::Application

config.redis_key_prefix = "jupiter.#{Rails.env}."

# Set an action on unpermitted parameters to raise an exception, used to validate parameters in Oaisys.
config.action_controller.action_on_unpermitted_parameters = :raise
Copy link
Contributor

@murny murny Jan 2, 2020

Choose a reason for hiding this comment

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

Curious the impact of this would be in production? Makes sense in Dev/Test over :log but with production could be troublesome perhaps and could result in a lot of crashes that would be difficult to troubleshoot?

For example say someone links a page on ERA on a 3rd party site, let's say Slack. Slack may add additional params to the link, e.g era.ualberta.library.ca/search?q=thesis&utm_source=slack for tracking. This would be an unpermitted param? Which means anyone clicking that link will get served a 500 error

Couldn't find much online to confirm this, except for this stackoverflow article:
https://stackoverflow.com/questions/57461284/action-on-unpermitted-parameters-on-production-environment
which highlights these same concerns.

Would you be able to verify this?

And if that is the case, maybe we just want to enable this in dev/test only

Copy link
Contributor Author

@ConnorSheremeta ConnorSheremeta Jan 6, 2020

Choose a reason for hiding this comment

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

Good points, it has been decided that were going to set it to raise for dev/test and false in prod. Going to go back to manually checking oai parameters.

Copy link
Contributor

@murny murny left a comment

Choose a reason for hiding this comment

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

Got some small concerns on setting config.action_controller.action_on_unpermitted_parameters = :raise in production. Can you double check this?

@ConnorSheremeta
Copy link
Contributor Author

Found an issue from doing config.action_controller.action_on_unpermitted_parameters = :raise... if the page is changed an exception is thrown as :page is not a permitted param on line 3 of search helper. I've made it permitted and added an .except(:page) which should not change anything as the default behaviour was to just filter the unpermitted parameters anyways

Some more context on the page parameter not being permitted in the place above. The page parameter is being permitted and used on line 64 of search_controller. Because it is permitted there doesn't mean it is permitted elsewhere as .permit returns a new ActionController::Parameters instance

@ConnorSheremeta
Copy link
Contributor Author

Note: this PR should probably be merged once the gemfile references an oaisys repo with all list identifiers commits (2 PRs are still open in oaisys)

@ConnorSheremeta
Copy link
Contributor Author

Now referencing final Oaisys list identifiers commit in the gemfile, ready to be merged (once approved).

Copy link
Contributor

@mbarnett mbarnett left a comment

Choose a reason for hiding this comment

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

Looks good to me

LGTM

@ConnorSheremeta ConnorSheremeta merged commit c474009 into ualbertalib:integration_postmigration Jan 10, 2020
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.

3 participants