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

Tco 19 snapshot dashboard #109

Merged
merged 4 commits into from
Oct 1, 2024
Merged

Tco 19 snapshot dashboard #109

merged 4 commits into from
Oct 1, 2024

Conversation

JPrevost
Copy link
Member

@JPrevost JPrevost commented Sep 23, 2024

Summary of changes (please refer to commit messages for full details)

Developer

Ticket(s)

https://mitlibraries.atlassian.net/browse/TCO-###

Accessibility

  • ANDI or Wave has been run in accordance to our guide and
    all issues introduced by these changes have been resolved or opened
    as new issues (link to those issues in the Pull Request details above)
  • There are no accessibility implications to this change

Documentation

  • Project documentation has been updated, and yard output previewed
  • No documentation changes are needed

ENV

  • All new ENV is documented in README.
  • All new ENV has been added to Heroku Pipeline, Staging and Prod.
  • ENV has not changed.

Stakeholders

  • Stakeholder approval has been confirmed
  • Stakeholder approval is not needed

Dependencies and migrations

NO dependencies are updated

NO migrations are included

Reviewer

Code

  • I have confirmed that the code works as intended.
  • Any CodeClimate issues have been fixed or confirmed as
    added technical debt.

Documentation

  • The commit message is clear and follows our guidelines
    (not just this pull request message).
  • The documentation has been updated or is unnecessary.
  • New dependencies are appropriate or there were no changes.

Testing

  • There are appropriate tests covering any new functionality.
  • No additional test coverage is required.

@mitlib mitlib temporarily deployed to tacos-api-pipeline-pr-109 September 23, 2024 17:22 Inactive
@JPrevost JPrevost temporarily deployed to tacos-api-pipeline-pr-109 September 23, 2024 17:44 Inactive
@JPrevost JPrevost requested review from jazairi and matt-bernhardt and removed request for jazairi September 23, 2024 17:45
@matt-bernhardt matt-bernhardt self-assigned this Sep 30, 2024
Copy link
Member

@matt-bernhardt matt-bernhardt left a comment

Choose a reason for hiding this comment

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

I have one non-blocking question about the structure of the ability model, and one head-shaking comment about what is necessary to actually grant permission to a resource. I'm fine with this merging as-is, though - thanks for putting this together to let folks see the sorts of metrics we're compiling.

:shipit:

@@ -7,12 +7,18 @@ class Ability
# See the wiki for details:
# https://github.com/CanCanCommunity/cancancan/blob/develop/docs/define_check_abilities.md
def initialize(user)
# Actions allowed for non-authenticated Users should add `skip_before_action :require_user`

# Start of Rules for all authenticated user with no additional roles required
Copy link
Member

Choose a reason for hiding this comment

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

This may be a minor point, so please ignore if you feel strongly...

I really like calling out the block of permissions like this - but it feels like the return if user.blank? line should come before this block starts?

Copy link
Member Author

Choose a reason for hiding this comment

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

I feel like the common ruby documentation practice is to document before the thing being documented. i.e. you document the Class before the Class class_name definition, you document the method before the def method_name. This feels in line with that expectation that docs come before the thing they are documenting.

# all authenticated
# can :view, :playground
can :manage, :detector__suggested_resource
can :manage, Detector::SuggestedResource
Copy link
Member

Choose a reason for hiding this comment

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

Am I seeing this correctly? Both of these lines appear to be required, for different reasons? One grants access to the resource, while the other is needed to get access to the dashboard?

If it works, it works, but ... huh.

Copy link
Member Author

Choose a reason for hiding this comment

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

It's complicated. I spent some time trying to understand how to avoid this, but it felt like it was going to require additional work in a possibly less maintainable way than just doubling up things in Ability. I wasn't sure how best to document it either.

Why are these changes being introduced:

* Allowing a way to access our historical matches over time will be
  useful

Relevant ticket(s):

* https://mitlibraries.atlassian.net/browse/TCO-63
* https://mitlibraries.atlassian.net/browse/TCO-19

How does this address that need:

* Adds Report index
* Adds Metrics Algorithm report with monthly and aggregate support

Document any side effects to this change:

* Updates ability.rb for SuggestedResources to handle the difference in
  syntax when working in Administrate context versus the rest of our app
@JPrevost JPrevost merged commit d362bc5 into main Oct 1, 2024
3 checks passed
@JPrevost JPrevost deleted the tco-19-snapshot-dashboard branch October 1, 2024 15:16
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