-
Notifications
You must be signed in to change notification settings - Fork 0
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
Add administrate gem ... #78
Conversation
6208d88
to
9c30c94
Compare
9c30c94
to
0963da4
Compare
0963da4
to
0ad9404
Compare
0ad9404
to
a6b88fa
Compare
fb5edf1
to
493a3c3
Compare
** Why are these changes being introduced: * We want to add the Administrate gem to the application, and use its dashboards to manage information within TACOS. ** Relevant ticket(s): * https://mitlibraries.atlassian.net/browse/TCO-51 ** How does this address that need: This does several things: * Adds the Administrate gem * Builds the default dashboards for several resources already in the application: Suggested Resources, Search Events, Terms, and Users * Adds a nav link to the admin area, visible only to users with the rights to see the Terms dashboard (the default display) * Starts to define the authorization checks in the admin application controller, which should in turn look to CanCan's ability model. The ability model itself is so far unchanged. ** Document any side effects to this change: * The only change to the generated dashboards was to remove the fingerprint field from the Suggested Resource form, because that value is calculated during save. * The fact that the Terms dashboard is the default display is a bit arbitrary, and a future ticket will expand our approach here to potentially include a "lobby" display for users with various rights.
493a3c3
to
1bab3fa
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.
Thanks for setting this all up! Everything looks right to me.
This also feels like a good place to share something I learned while researching the issue we were having yesterday with the 'lobby' view. It seems likely that the issue is not with administrate, but with using CanCanCan without a model. If I'm correct about that, then we need to do two things to get authorization to work properly with the Stat/StatDashboard resource, as suggested here:
- In the controller, specify that there is no associated model:
authorize_resource class: false
- In the Ability model, name the resource as a symbol:
can :read, :stat
I tried the above yesterday and it didn't work for me. It was at the end of the day, though, so it might be worth digging into with fresh eyes. (I suspect I was doing something wrong with pluralization.)
|
||
# Override this value to specify the number of elements to display at a time | ||
# on index pages. Defaults to 20. | ||
# def records_per_page |
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 assume this method was generated by the administrate install? I'm fine keeping it in; just want to make sure it wasn't a leftover comment from a WIP.
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.
Yeah, this was what the generator put in place - I remember noting it while working, and thinking "huh, I wonder if we'll ever actually use that".
Ooh, interesting! Thanks for finding this. I've added it as a reference in the follow-up ticket: https://mitlibraries.atlassian.net/browse/TCO-63 |
This adds the Administrate gem, and uses the built-in generator for dashboards for four existing resources:
Notable changes to the generator are:
require_user
method in addition toauthorize_user
, to ensure relevant error messages in all cases (confirmed with tests)There is also a conditional link in the navigation, shown only to users who have the ability to access the default dashboard (currently set to the Terms area, but will change in a future ticket). This is a divergence from the pattern we're using in ETD, where the nav link is conditional on the admin flag on the User model (which I think is a pattern to avoid).
In hindsight, I think this PR would have been cleaner to have one commit of the generator output, and then a second commit to make the customization changes. If the reviewer would rather see this structure, let me know and I'll restructure accordingly.
Developer
Ticket(s)
https://mitlibraries.atlassian.net/browse/TCO-51
Accessibility
all issues introduced by these changes have been resolved or opened
as new issues (link to those issues in the Pull Request details above)
Documentation
ENV
Dependencies and migrations
YES dependencies are updated
NO migrations are included
Reviewer
Code
added technical debt.
Documentation
(not just this pull request message).
Testing