Add values_editable_by support to github_organization_custom_properties

[markszabo]

Resolves #2930

---

Before the change?

The github_organization_custom_properties resource does not support the values_editable_by field. On the UI this is called Allow repository actors to set this property and can be set to either Enabled or Disabled. In the API (and go-github) it is called values_editable_by and can be set to org_actors (default), org_and_repo_actors.

After the change?

The github_organization_custom_properties resource now supports the values_editable_by field with values org_actors (default) or org_and_repo_actors.

• values_editable_by - (Optional) Who can edit the values of the custom property. Can be one of org_actors or org_and_repo_actors. When set to org_actors (the default), only organization owners can edit the property values on repositories. When set to org_and_repo_actors, both organization owners and repository administrators with the custom properties permission can edit the values.

Pull request checklist

• Schema migrations have been created if needed (example)
• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• Yes
• No

This adds a new, optional field who's default value matches the current behavior.

[sheplu]

I was looking to add the same PR to fix this missing property on the provider!
+1

[deiga]

@markszabo Thank you for your contribution! 🎉

I'd like to ask you for a few more additions:

• Could you add a test that verifies that this change won't affect existing values of the values_editable_by field in the API?
• Since the values_editable_by field has a specific list of values it accepts, could you add validation to check it's values? :)

[markszabo]

@deiga thank you for the review, I made the requested changes. Let me know what you think :)

[deiga]

Amazing, Thank you!

[stevehipwell]

LGTM

@nickfloyd are you running local tests on PRs before merging them?

[nickfloyd]

@nickfloyd are you running local tests on PRs before merging them?

Always. It's a bit of a slog, but it's currently the best approach for verification that we have.

[stevehipwell]

Always. It's a bit of a slog, but it's currently the best approach for verification that I we have.

Hopefully #2946 will be able to make this less of a challenge.