Issue/4756 Allow use of Settings Writing defaults for XML-RPC and non-admin users

[kurzee]

As seen in #4756, this allows XML-RPC and non-admin users to change their writing defaults for use within the app without syncing to the site.

This also adds a bit of text to the section label for "Writing" for users who are only updating these settings locally. Currently this is "Writing (App Defaults)", let me know of any feedback on the wording.

I'm not 100% sure this is the best solution for what's going on here. Should we instead disable these fields altogether for any users who can't sync these options to this site?

XML-RPC Testing

1. Open Site Settings for an XML-RPC site as an admin user.
2. Writing options for Default Post Category and Default Post Format should be available.
3. The section label for writing should note that these are for use within the app only.
4. Selecting a new category or post format should update the setting within the app without error.
5. Posting via the editor should use these selected defaults.

REST Testing

1. Open Settings for a REST site as an admin user.
2. Writing options for Default Post Category, Default Post Format and Related Posts should be available.
3. Changing any of these settings should update the app's defaults and the site's.

REST Testing

1. Open Settings for a REST site as a non-admin user.
2. Writing options for Default Post Category and Default Post Format should be available.
3. Selecting a new category or post format should update the setting within the app without error.
4. Posting via the editor should use these selected defaults.

@aerych Please review, also @SergioEstevao may have some thoughts?

[aerych]

Screenshot for posterity

I'm digging the header, but I'm wondering if it would be overkill to add a footer as well? Pinging @mattmiklic for a design eye.

[kurzee]

A footer would help explain it a bit more, something along the lines of "Default settings here are used when posts are created within the iOS app."

[mattmiklic]

I'd recommend changing the header to read "This Device", so it matches the organization and terminology we used for device-level settings on Android. I think the "This Device" header is descriptive enough that no footer would be necessary.

[kurzee]

@mattmiklic ah, that's perfect. Thanks!

[SergioEstevao]

@kurzee, @mattmiklic My only question here, shouldn't Geotagging always be on the device settings? at the moment I see it on device setting for self-hosted and for sites were we don;t have permission to change the default category and format. But on WP.com sites where we have permission I see it on Writing settings and I don't think that this setting is sync with the server.

[mattmiklic]

shouldn't Geotagging always be on the device settings? at the moment I see it on device setting for self-hosted and for sites were we don;t have permission to change the default category and format. But on WP.com sites where we have permission I see it on Writing settings and I don't think that this setting is sync with the server.

Yep, good call. That should stay under "This Device" on iOS as it did on Android.

[kurzee]

@SergioEstevao @mattmiklic that's correct, Geotagging is only ever set locally within the app and not synced to the server.

[kurzee]

@mattmiklic @SergioEstevao actually, if we get rid of the "Writing" header, and use only "This Device" then we should also disable the syncing of these defaults settings? I was originally thinking we would replace the header as "Writing (This Device)" for users that can't sync the setting back to the server.

[mattmiklic]

I would put anything that we can't sync back to the server under the "This Device" header. If we're able to sync the default category and post format, then it should be under the Writing section. If not, This Device is right.

[kurzee]

Still seems a bit odd to have two different types of functionality for the post defaults.

In one scenario a user who can sync the defaults can change the options in-app and site-wide, but not one or the other.

In the other scenario, users who cannot sync can change the defaults for use in-app without affecting the site. I could imagine this to also be desirable for users who want in-app defaults differing from their site-wide defaults.

Would it be better if the app only changed default post options for within the app, and did not try and sync the defaults?

Or, if we are shooting for parity with Calypso on the web, we should only display the option for changing the default category and post format for users who can sync. Users who cannot sync would not have the default options, as seen on the web.

[mattmiklic]

Or, if we are shooting for parity with Calypso on the web, we should only display the option for changing the default category and post format for users who can sync. Users who cannot sync would not have the default options, as seen on the web.

I think this makes the most sense.

[kurzee]

Thanks guys. New PR for resolving this differently: #4766, will close this one un-merged if we don't go this route.