Update the version detail API to report host_permissions

[bobsilverberg]

This is a follow-up to #9104. Once we are storing host_permissions for MV3 add-ons, we should update the API to return those stored host_permissions.

┆Issue is synchronized with this Jira Task

[eviljeff]

I think we should hold off on this until we know what the actual need/request is. What frontend is going to display, and how - if it's just that the urls aren't omitted from the permissions block for MV3 add-ons the serializer should just return both urls and permission names in the existing permissions field.

[bobsilverberg]

With the filing of #14670, it looks like we're going to need this. Based on the lengthy discussion at #9104, I feel like the following are our best options:

1. Add a property to the API response for host_permissions, returning exactly what we find in host_permissions in the manifest.
2. Take the contents of host_permissions from the manifest and add them to optional_permissions in the API response. This is based on this comment that says that host_permissions are optional permissions.

As discussed in the other issue, I am in favour of 1. It does involve some extra processing on the client, but it also means we aren't coupling the API response to our specific UX requirements at this time. My concern with option 2 is that, if we decide to do something different with host_permissions on the client in the future, this will necessitate an API change.

@diox @eviljeff @kplotnik What do you think?

[willdurand]

Take the contents of host_permissions from the manifest and add them to optional_permissions in the API response. This is based on this comment that says that host_permissions are optional permissions.

This is going to mix API and host permissions, which MV3 solved with the introduction of host_permissions. Also, as I mentioned, there might be some optional_host_permissions key in the future.

[eviljeff]

Note the MV2 add-ons (the vast bulk of extensions on AMO today) mix the host and API permissions, and frontend processes them to display them separately* (in the same card). So we should consider how MV2 permissions are handled too.

*option 1 would, as far as a I understand it, lead to less processing on the client, because host and API permissions wouldn't need to be split out from a single list of optional permissions(?)

[willdurand]

Note the MV2 add-ons (the vast bulk of extensions on AMO today) mix the host and API permissions

Yes, but they are also all required so that makes sense.

and frontend processes them to display them separately* (in the same card). So we should consider how MV2 permissions are handled too.

Are they displayed separately? My understanding is that we have two sections, and for each, we have both API and host permissions. In the screenshot below, we only have host permssions (some required, some optional):

And here we have both API and host permissions, all required:

[eviljeff]

Are they displayed separately?

Separately on the same card. From #9104

We are already reporting regular and host permissions in the same card on the front-end, although we do process them so host permissions will show up last.

[ioanarusiczki]

@bobsilverberg

I tried with MV2 and MV3 -> the detail/version endpoints return permissions , optional permissions and host permissions

[KevinMind]

Old Jira Ticket: https://mozilla-hub.atlassian.net/browse/ADDSRV-276