Sharing: not accessible for editors and author on Jetpack sites

[jkudish]

The /sharing screen is not accessible for non-admins on a Jetpack site. Specifically editors should be able to fully manage connections and authors should be able to add/remove their own connections (but not make them shared).

This works 100% as expected for WordPress.com sites (except for a notice that is fixed with #1653)

I believe the main issue is that the page checks isModuleActive( 'publicize' ) which returns false because non-admins can't access Jetpack modules.

[mtias]

The isModuleActive check is also annoying for things like this: #1425.

[lezama]

I am going to add the array of active modules to /me/sites/ and /sites/%site%/ endpoints responses, independent of the user capabilities, sounds good?

[mtias]

@lezama finalmente :)

[aduth]

I am going to add the array of active modules to /me/sites/ and /sites/%site%/ endpoints responses, independent of the user capabilities, sounds good?

Would this make module status available for unauthenticated users? While I personally don't have a problem with Jetpack module status being made available publicly, this diverges from existing capabilities checks for /sites/%s/jetpack/modules. Any changes should be consistent between the two endpoints.

Adding to the site endpoints may also increase the response time already slow endpoints, and worsens the problem of the site endpoint being a dumping ground.

See also: D509

[mtias]

Adding to the site endpoints may also increase the response time already slow endpoints, and worsens the problem of the site endpoint being a dumping ground.

In this case, I think it's so fundamental to the site that it helps the development and user experience.

[lezama]

Adding to the site endpoints may also increase the response time already slow endpoints

It only implies one more get_option call per Jetpack site, is that too much?

[aduth]

I think there's more legitimacy to including Jetpack module status than some of the other attributes that have been added to the site endpoint, so I'm not very concerned about it. Outside this case, I think we shouldn't be afraid to make network requests to appropriate endpoints, and perhaps we can be doing more caching to lessen the effect on the user-experience.

[mtias]

Yes, I completely agree with that.

[lezama]

I think we shouldn't be afraid to make network requests to appropriate endpoints, and perhaps we can be doing more caching to lessen the effect on the user-experience.

Definitely

[jkudish]

Why not just adjust the permissions on the existing modules endpoint?

[jkudish]

Noting that this blocks 266-gh-io that we're trying to push forward this week if possible.

[mtias]

Why not just adjust the permissions on the existing modules endpoint?

It'd allow us to render all the sidebar items before hitting the extra endpoints, which avoids the shuffling of items.

[lezama]

Why not just adjust the permissions on the existing modules endpoint?

Probably we will experience the same #1425 is reporting, we can render everything without extra network requests.

D712 should fix both problems

[jkudish]

Fixed by #1700