DevHub Pastebin Re-implementation

[chrstinalin]

Fixes: mozilla/addons#14998

Description

Surfaces attachments on the DevHub side, allowing developers to download reply attachments.

Testing

1. Enable the enable-activity-log-attachments waffle switch.
2. Log in with [email protected] (for ease of navigation).
3. Submit a new add-on.
4. Make a reviewer reply (or any other action) from the review action section and include an attachment.
5. Navigate to the 'Manage Status & Versions'. Click 'Review History' under 'Status' of the replied-to version.

Checklist

• Add #ISSUENUM at the top of your PR to an existing open issue in the mozilla/addons repository.
• Successfully verified the change locally.
• The change is covered by automated tests, or otherwise indicated why doing so is unnecessary/impossible.
• Add before and after screenshots (Only for changes that impact the UI).
• Add or update relevant docs reflecting the changes made.

[KevinMind]

Trying to verify I caught something.. how is the URL being defined? I see the get_attachment_url using revers() but also saw in the browser a relative URL.

@diox can you clarify I can't remember if we need special care for ensuring the site URL is included as the URL root.

Also clicking the URL in local dev resulted in infinite redirects and eventually a failure.

[chrstinalin]

Also clicking the URL in local dev resulted in infinite redirects and eventually a failure.
@KevinMind

I pointed it out in the other PR, but it seems to have something to do with the constants? Removing them makes the link work as expected, but including them causes the infinite redirect. Since there was extra work to be done with frontend (syncing the constants), I had assumed the lack of constant-syncing was the issue.

[diox]

On local environments, where requests are proxied through addons-frontend, it should work fine if your addons-frontend container is up to date with the changes from mozilla/addons-frontend@c09adf0

The reason it works if you remove the constants is that then it makes a redirect to /{locale}/activity/..., but we want to avoid that.

On dev/stage/prod we'll need SRE to update nginx config in https://github.com/mozilla-it/webservices-infra/blob/main/amo/k8s/amo-proxy/configs/addons.conf.tpl to make /activity be served by addons-server.

[KevinMind]

@diox curious why did we not opt for /downloads root? This is for downloading an attachment.. I saw the conversation in @chrstinalin linked ticket but maybe I missed something.

[KevinMind]

I just discovered we are currently not defaulting to pulling latest image of dependencies like addons-frontend that should probably be the case. I totally missed that my frontend was 7 days stale.

[KevinMind]

@chrstinalin okay good news, new error. But still an error. now I'm getting RelatedObjectDoesNotExist looking for the attachment log.

I did the following:

• navigate to listed review page
• rejected the version with a "copy from pastebin" text I just entered random words
• nvagiate to status and versions page
• click view history
• I see the attachment link and click
• I see this error page.

Any idea what could be happening?

[chrstinalin]

@KevinMind Whoops. Reverse is using the wrong ID

[diox]

/downloads is not a bad idea, although currently, /downloads is defined from olympia.versions.urls, and this is not really tied to a version at all... and we already had activity views/URLs...

(Also, atm downloads is considered app-specific - we'd want to fix mozilla/addons#1871 before adding more stuff under that path IMHO)

[KevinMind]

Verified working locally. LGTM