You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The pair_retro create route is reimplementing a lot of logic that should in theory be handled by Canary. Evaluate whether this code can be improved through the use of Canary.
Some fiddling reveals that this is probably a bit more complicated than simply adding the :create action to the load_and_authorize_resource, as the Canada protocol doesn't seem to pick up the user_id of the retro, as it is passed in as a parameter nested in the pair_retro parameter. So conn.assigns.authorized will be true for admins, but not when the passed in nested user_id parameter matches the user id of the logged in user in .conn.assigns.current_user.
This might be as simple as figuring out what to match on in this case in the Canada protocol, or it may involve some more in depth logic. Could be a good opportunity for a PR to Canada or Canary.
It's also possible that the solution is actually less elegant than the currently existing code. In which case this would be closed with no code change.
The text was updated successfully, but these errors were encountered:
Closing this for now, as after some further investigation, this is a pretty substantial change to canary, and the a lot of the complexity in this method will be removed once we move to Phoenix 1.3 and get FallBackControllers.
The pair_retro create route is reimplementing a lot of logic that should in theory be handled by Canary. Evaluate whether this code can be improved through the use of Canary.
Some fiddling reveals that this is probably a bit more complicated than simply adding the
:create
action to theload_and_authorize_resource
, as the Canada protocol doesn't seem to pick up the user_id of the retro, as it is passed in as a parameter nested in the pair_retro parameter. Soconn.assigns.authorized
will be true for admins, but not when the passed in nested user_id parameter matches the user id of the logged in user in.conn.assigns.current_user
.This might be as simple as figuring out what to match on in this case in the Canada protocol, or it may involve some more in depth logic. Could be a good opportunity for a PR to Canada or Canary.
It's also possible that the solution is actually less elegant than the currently existing code. In which case this would be closed with no code change.
The text was updated successfully, but these errors were encountered: