-
Notifications
You must be signed in to change notification settings - Fork 30
feat: add delegation commands #210
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
Conversation
I've modified the undelegation logic to require either elif command.action == 'undelegate':
# TODO: why is this a TRY?
if not _try_auth_verified():
continue
state.delegate = ''
state.save() So I guess #206 will need updating. |
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.
Thank you! Implementation looks good at a first glance, but I have to say that I forgot about @bors delegate=<username>
. That sounds a bit.. useless, to be honest, and could be a potential security problem if someone mispells the name, since some other user could then get approval rights. Or a user could rename themselves to get approval rights (in theory). In general, we should try to store user GitHub IDs instead of usernames, but in this case I think we can just store a boolean property (delegated/not delegated).
I think that delegate+
and delegate-
should be enough. I asked others about this here.
Yeah let's just keep |
5de0a71
to
18f5bad
Compare
I've removed it. DB wise: |
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.
There is kind of a glaring security hole in the current implementation 😆 But should be easy to fix.
The tests will also require some modifications to actually test a situation with multiple users. In particular, there should be a test where person A creates a PR, person B delegates it, and then person C tries to approve, but it fails. This would find the "security hole" xD
But otherwise it looks very good!
70dbff1
to
ab5d8a7
Compare
Btw, when you are implementing review remarks, it's fine to keep pushing individual commits, we can always squash at the very end just before merging. It is easier to review the changes more separately, rather than checking a big force push that changes the whole PR. |
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.
Thank you! Left a few more comments.
I think that it works now, but could you please also add a test that a (non-PR-author) user with try permissions cannot delegate? Thanks! |
b70199c
to
d03732a
Compare
Let's just say I got into a fight with git. I'll fix it though - should be good git practice. |
8619570
to
feddf97
Compare
feddf97
to
47c68df
Compare
Added |
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.
Thank you, awesome work!
Fixes: #209
Fixes: #129