[PATCH 2/4] models, templates: Add submission relations

Daniel Axtens dja at axtens.net
Thu Jan 16 00:06:40 AEDT 2020


Picking this up again...
>> +    by = models.ForeignKey(User, on_delete=models.CASCADE)
>
> Again, I'm not a fan of this /o\ We already have a mechanism for
> tracking who does stuff - 'Events'. Instead of doing this, could we
> create a new event type and create these instead? That would provide a
> far more detailed audit trail to boot, since we could track removals as
> well as additions (assuming the former is allowed).

I have to bump up the size of the category field because
'patch-relation-changed' is longer than 20 characters.
>
>> +
>> +    def __str__(self):
>> +        return ', '.join(s.name for s in self.submissions.all()) or '<Empty>'

I've made this cut off after 60 chars (and only consider the first 10
patches) so as not to overwhelm the admin view. Oh, I also added an
admin view.

>> +
>> +
>>  @python_2_unicode_compatible
>>  class Check(models.Model):
>>  
>> diff --git a/patchwork/templates/patchwork/submission.html b/patchwork/templates/patchwork/submission.html
>> index 77a2711ab5b4..bb0391f98ff4 100644
>> --- a/patchwork/templates/patchwork/submission.html
>> +++ b/patchwork/templates/patchwork/submission.html
>> @@ -110,6 +110,43 @@ function toggle_div(link_id, headers_id, label_show, label_hide)
>>    </td>
>>   </tr>
>>  {% endif %}
>> +{% if submission.related %}
>> + <tr>
>> +  <th>Related</th>
>> +  <td>
>> +   <a id="togglerelated"
>> +      href="javascript:toggle_div('togglerelated', 'related')"
>> +   >show</a>
>> +   <div id="related" class="submissionlist" style="display:none;">
>> +    <ul>
>> +     {% for sibling in submission.related.submissions.all %}
>> +      <li>
>> +       {% if sibling.id != submission.id and sibling.project_id == project.id %}
>> +        <a href="{% url 'patch-detail' project_id=project.linkname msgid=sibling.url_msgid %}">
>> +         {{ sibling.name|default:"[no subject]"|truncatechars:100 }}
>> +        </a>
>> +       {% endif %}
>
> You need to preload these here too, like you do in the REST API, to
> prevent the database getting hammered.
>
AFAICT the refactored (patch only) one doesn't require this, but with
some tomfoolery I can reduce the load on the database even more with
judicious use of .only, and by not going out to the database again for
related_outside (which I have renamed related_different_project).

>> +      </li>
>> +     {% endfor %}
>> +     {% if related_outside %}
>> +      <a id="togglerelatedoutside"
>> +         href="javascript:toggle_div('togglerelatedoutside', 'relatedoutside', 'show from other projects')"
>> +      >show from other projects</a>
>> +      <div id="relatedoutside" class="submissionlist" style="display:none;">
>> +       {% for sibling in related_outside %}
>> +        <li>
>> +         <a href="{% url 'patch-detail' project_id=sibling.project.linkname msgid=sibling.url_msgid %}">
>> +          {{ sibling.name|default:"[no subject]"|truncatechars:100 }}
>> +         </a> (in {{ sibling.project }})
>> +        </li>
>> +       {% endfor %}
>> +      </div>
>> +     {% endif %}
>> +    </ul>
>> +   </div>
>> +  </td>
>> + </tr>
>> +{% endif %}
>>  </table>
>>  
>>  <div class="patchforms">
>> diff --git a/patchwork/views/patch.py b/patchwork/views/patch.py
>> index f34053ce57da..0480614614ad 100644
>> --- a/patchwork/views/patch.py
>> +++ b/patchwork/views/patch.py
>> @@ -110,12 +110,19 @@ def patch_detail(request, project_id, msgid):
>>      comments = comments.only('submitter', 'date', 'id', 'content',
>>                               'submission')
>>  
>> +    if patch.related:
>> +        related_outside = patch.related.submissions \
>> +            .exclude(project=patch.project)
>> +    else:
>> +        related_outside = []
>> +
>
> I'm not sure why this exists. Could you add some additional context to
> the commit message? In any case, I think it would be more performant to
> just prefetch the related patches and do this filtering in the view.
>

As per above, this is now related_same_project and
related_different_project, it exists on my suggestion so that relations
across different projects show up separately. This means that if you're
looking at linuxppc-dev at a series cross-posted to the pci list, the
relations created in different projects are visible if you care to
explore them, but are not forced on you.

>>      context['comments'] = comments
>>      context['checks'] = patch.check_set.all().select_related('user')
>>      context['submission'] = patch
>>      context['patchform'] = form
>>      context['createbundleform'] = createbundleform
>>      context['project'] = patch.project
>> +    context['related_outside'] = related_outside
>>  
>>      return render(request, 'patchwork/submission.html', context)
>>  
>
> I was going to ask why you did patch relations rather than series
> relations, but I'm guessing PaStA works on a patch level? No issues
> with that, but it would be nice to reuse the relationship information
> to link series somehow. I've no idea how that would happen though, so
> we can probably think about that later.
>
> Stephen
>
> _______________________________________________
> Patchwork mailing list
> Patchwork at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/patchwork


More information about the Patchwork mailing list