-
Notifications
You must be signed in to change notification settings - Fork 83
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
[Issue #507] Allow non delegate users to declare interest in a patch #588
base: main
Are you sure you want to change the base?
Conversation
I have seen this 👀 but I'm going to leave comments on the issue and discuss things there before looking at this. |
4e1c212
to
2eb1ae1
Compare
I am not certain this solves #507. I can see from the code that there have been changes to model and patch structures to store users interested in the patch, but I don't see anywhere changes to actual user interface. I also run this code using docker-compose on my machine and I don't see any way to show interest in the patch? Am I missing something? |
@hero24 were you unable to declare interest on a patch when running it on a container? I missed to add a button for it on the UI, I'll add an extra commit with it |
@andrepapoti I will retest this later and let you know if it works through API for me, When I was testing this, I focused on web interface. I think most people use patchwork through web interface (it would actually be an interesting metric to conduct, but that beyond of the scope), but yes I could not find an add interest button through web, or any other way to declare interest through web interface. |
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.
Seems to be working didn't check the cronjob though
@stephenfin I took a closer look into this feature and from the issue it seems we should only be able to declare interest in a series and not on specific patches, is this correct? Also how the interest should be handled in the case of another series superseding the current one, the review should be moved to the new series or should just be deleted? |
8fccaac
to
d9abfce
Compare
d9abfce
to
bef562f
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.
This is looking pretty good. There are, however, three main changes I'd like to see:
- Rename the models and fields, per comments.
- Ensure attention set entries can be "soft deleted", so that maintainers can tell that one existed in the past
- Consider dropping the concept stale review requests from Patchwork itself and instead document how one can do this via the API.
patchwork/models.py
Outdated
@@ -729,6 +736,15 @@ class Meta: | |||
] | |||
|
|||
|
|||
class PatchReviewIntention(models.Model): |
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 quite like the "attention set" term since it allows us to capture both a review intention and a review request. Can we use it?
class PatchReviewIntention(models.Model): | |
class PatchAttentionSet(models.Model): |
patchwork/models.py
Outdated
class PatchReviewIntention(models.Model): | ||
patch = models.ForeignKey(Patch, on_delete=models.CASCADE) | ||
user = models.ForeignKey(User, on_delete=models.CASCADE) | ||
last_time_marked_for_review = models.DateTimeField(default=tz_utils.now) |
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.
Can we rename this field to simply last_updated
. I also wonder if we could/should track removals from this set? If we do, I think we likely only need to track the most recent request.
last_time_marked_for_review = models.DateTimeField(default=tz_utils.now) | |
last_updated = models.DateTimeField(auto_now=True) | |
removed = models.BooleanField(default=False) | |
removed_reason = models.CharField(max_length=50) |
patchwork/models.py
Outdated
last_time_marked_for_review = models.DateTimeField(default=tz_utils.now) | ||
|
||
class Meta: | ||
unique_together = [('patch', 'user')] |
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.
Assuming the above.
unique_together = [('patch', 'user')] | |
unique_together = [('patch', 'user', 'removed')] |
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.
Because the GitHub UI won't let me leave comments on the commit message: please wrap commit messages at <= 72 characters.
class Migration(migrations.Migration): | ||
dependencies = [ | ||
('patchwork', '0047_add_database_indexes'), | ||
migrations.swappable_dependency(settings.AUTH_USER_MODEL), |
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'm guessing this was auto-generated? I didn't see it pop up in the most recent series. Could you regenerate this?
patchwork/api/patch.py
Outdated
@@ -428,7 +428,7 @@ def has_object_permission(self, request, view, obj): | |||
if 'planning_to_review' in data: | |||
for review_data in data: | |||
user_id = review_data['user'] | |||
if request.user.id == reviewing_user: | |||
if request.user.id == user_id: |
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.
Can you squash this change back into the earlier commit that added this view.
patchwork/api/patch.py
Outdated
@@ -172,6 +203,8 @@ class Meta: | |||
'hash', | |||
'submitter', | |||
'delegate', | |||
'planning_to_review', |
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.
'planning_to_review', | |
'attention_set', |
patchwork/api/patch.py
Outdated
@@ -172,6 +203,8 @@ class Meta: | |||
'hash', | |||
'submitter', | |||
'delegate', | |||
'planning_to_review', | |||
'has_planned_review', |
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.
'has_planned_review', |
patchwork/api/patch.py
Outdated
intereted_user = patchreviewintention_set.pop()['user'] | ||
instance.planning_to_review.add(intereted_user.id) |
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.
s/intereted/interested/
return super(PatchDetailSerializer, self).update( | ||
instance, validated_data | ||
) | ||
return |
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.
Is this correct? Could you add a comment explaining why we're returning without calling super()
?
Patches that needs the attention of a specific user can now be linked to them by the attention set field. Attention flags by default are soft deleted. Signed-off-by: andrepapoti <[email protected]> Signed-off-by: Victor Accarini <[email protected]>
Users can now add/remove themselves from a patch attention list if they want to sinalize that they will look into it. To add themselves to the attention list they must execute a patch with a list with their IDs in the `attention_set` property. To remove themselves they must send a list with their negative IDs or an empty list. Maintainers can also remove anyone from the attention list by sending a list with negative IDs. Signed-off-by: andrepapoti <[email protected]> Signed-off-by: Victor Accarini <[email protected]>
* List view: show number of users interested in a specific patch * Detail view: show a list of users who are interested in the patch * Allow users to add/remove interest in a patch * Allow managers to remove interested user from a patch Signed-off-by: Victor Accarini <[email protected]>
Signed-off-by: Victor Accarini <[email protected]>
Signed-off-by: Victor Accarini <[email protected]>
Signed-off-by: Victor Accarini <[email protected]>
Signed-off-by: Victor Accarini <[email protected]>
@stephenfin I executed some of the request changes but also refactored a little @andrepapoti solution.
Edit:
|
Description
Add the relation between an user and a patch through the Patch's
interested_users
attribute.This relations happens through the model
PatchInterest
that contains a timestamp for when the interest was declared.Inside a
Patch
'sState
there's now an attribute indicating how long an interest can last before it expires.To remove expired interests async tasks were added using Celery
Serializers and Forms were update to reflect the changes aswell
Related