Allow artists to create and edit their own albums and profile #58
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We want to allow artists to administer their own releases/pages etc. At least initially we don't want this to be a free-for-all, we'll invite users to admin artists that we have created in the system. As a first step this commit allows signed in users to invite new users. The mechanism for this (creating them a user account with a password and then sending a password reset) is cribbed from the authentication-zero gem's `--invitable` generator, in particular the InvitationsController[1]. I've set an expiry time of 1 day on this password reset token, as it will probably take a user a bit longer to respond than if they requested the password reset themselves. I think we can definitely make some improvements to the usability of this flow, but for now I think this is sufficient. An obvious problem with this as it stands is that all users created have the same permissions, so we'll need to add some kind of role-based system to fix that. [1] https://github.com/lazaronixon/authentication-zero/blob/0eb2ba99c4b46b856066bcbc1d1ece42bd87887b/lib/generators/authentication/templates/controllers/html/invitations_controller.rb.tt
We want an invited user to be able to administer one or more artists. This migration sets up the necessary referrences. It's not clear to me that we would want to destroy an artists and all their releases if a user model was destroyed, so I'm kicking that can down the road a bit with `restrict_with_exception`.
This will allow us to authorize the user to manage their associated artist later.
We need a way of distinguishing between admin users (who can currently do anything) and other users. I considered adding a "role" here, but I think we can differentiate between admins and users who can administer artists by the `has_many :artists` association.
We want to allow admin users and regular/artist users to do different
things. I've decided to use Pundit to encapsulate these authorisation
concerns as I'm familiar with it from another project.
I ran the `pundit:install` generator and added
after_action :verify_authorized
to the top of the ApplicationController. This causes each controller
action to raise an exception if the `authorize` method hasn't been
called. I then implemented authorization rules for each controller in
turn to maintain the existing application behaviour:
- the two existing users (James and Chris) in the database are
`admin` users set and can perform all of the existing actions
- new users invited using the invitation mechanism in previous
commits will not have the admin boolean. They, for now, can only
view the session index, home page and edit/update their passwords.
To keep this commit somewhat manageable it does not hide any content
in the views from non-admin users. We'll do that in a subsequent
commit. We can also tighten up the `index` logic using Pundit's
scopes.
I've introduced a NullUser to avoid having to check for the presence of Current.user in the view conditional - we can rely on the policy directly to do this for us.
We need a convenient place to store action links for users. Currently we have the /home page, but this isn't very easy to find. I think this menu provides a nice place to store these links and adds a little additional visual interest to the top of the page. The implementation of this toggle-able menu closely follows Adam Wathan's tutorial[1]. In particular the full-screen hidden button (bound to the `avatar-menu#close` action) is used to dismiss the menu by clicking outside of its bounds. I've also added a `avatar-menu#escape` function bound to the `keydown` event on the global `document` scope (with `keydown@document`) to provide an accessible way of dismissing it. I've pulled in a users "gravatar" if available[2] passing the `?d=mp` option[3] to have a fallback "mystery person" if the user doesn't have a gravatar set. We may want to improve this with a profile image upload later. [1] https://www.youtube.com/watch?v=If6XdbBQqmY [2] https://docs.gravatar.com/general/hash/ [3] https://docs.gravatar.com/general/images/
The links on this page are now contained in the avatar menu, so we no longer need this page. Where we were previously redirecting to this page, we're now redirecting to the `root_path` instead. I've added a flash notice to that page to capture any messages that were previously shown on home. Note with this commit we lose a direct link to Sessions#index. I think it's helpful to have this page around for debugging purposes, but I don't know if we need to link "regular" users to it for now.
This email address is now shown in the avatar menu instead.
This ensures this value doesn't linger in the session and get used on subsequent logins.
If an artist belongs to a user we want that user to be able to add new albums from the artist show page.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #27