package_upload does not list sponsor

Bug #1898861 reported by Robie Basak
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
High
Unassigned

Bug Description

When a package is in an unapproved queue, I'd like to be able to associate the package_upload object with the person who created the upload. This would be the signer of the changes file if uploaded directly to the queue, or the person who copied it in in the case of a copy.

The reason is that I'd like to be able to communicate with this person directly in case of questions. Without that I can only use a rejection with a rejection comment (which may not be appropriate if after communication and understanding I would have decided to accept the upload) or I have to try to guess based on the changelog entry - but the changelog entry won't necessarily be the sponsor so I have to ask about.

I found bug 861488 which added a creator_link attribute to spph. I wonder if you could do the same to package_upload - because an spph doesn't exist yet at this point?

Tags: api lp-soyuz
Revision history for this message
Robie Basak (racb) wrote :

It might also be useful to list the sponsor on the queue page (eg. https://launchpad.net/ubuntu/focal/+queue?queue_state=1) - as it's not available by looking at the changes file which is already linked.

Changed in launchpad:
status: New → Confirmed
Revision history for this message
Colin Watson (cjwatson) wrote :

Does the logic in this method look right? It's in internal Launchpad-speak, but hopefully reasonably transparent.

    def findPersonToNotify(self):
        """Find the right person to notify about this upload."""
        spph = self.findSourcePublication()
        spr = self.sourcepackagerelease
        if spph and spr.upload_archive != self.archive:
            # This is a build triggered by the syncing of a source
            # package. Notify the person who requested the sync.
            return spph.creator
        elif self.signing_key:
            return self.signing_key.owner
            # It may be a recipe upload.
        elif spr and spr.source_package_recipe_build:
            return spr.source_package_recipe_build.requester
        elif self.contains_copy:
            return self.package_copy_job.requester
        else:
            return None

If that's right, then we just need to figure out how to export it. I don't think it can be exported as an attribute of the `package_upload` object as it stands, because unless we were very careful, having to run that method in order to construct the JSON serialization of that object would add a couple of database queries every time you fetch such an object, and worse for collections of them. However, we could export it as a method without too much difficulty. I don't think `findPersonToNotify` would be the right name for an API export since API callers won't typically be doing notifications, but I guess we can come up with something else.

tags: added: api lp-soyuz
Changed in launchpad:
status: Confirmed → Triaged
importance: Undecided → High
Revision history for this message
Robie Basak (racb) wrote :

The logic looks right to me - thanks!

Revision history for this message
Robie Basak (racb) wrote :

(except that I don't think an spph will exist yet for an upload in Unapproved?)

Revision history for this message
Colin Watson (cjwatson) wrote :

Indeed it won't, but that's why it falls back to checking `self.signing_key` etc. in that case.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

To be fair direct signing_key_id of the .changes file of uploads would be really good https://api.launchpad.net/devel/ubuntu/mantic/+upload/31667614

as right now, we can't really tell who did the dput.

Alternatively, it would be nice for packages in New queue to have https://api.launchpad.net/devel.html#package_upload_log entry that goes for status "non-existing" to "new" as done by "uploader".

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.