-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feat/432 add new filters to provide more granular control #459
Feat/432 add new filters to provide more granular control #459
Conversation
@dkotter Wanted to double check on your intention from #432. You had mentioned to update |
@bjorn2404 Thanks for the questions!
So this would work for image generation but only if that is triggered via the REST API. This should be true for most use cases, someone in theory could directly use the methods within the In essence what I'm thinking is it's very likely that a client will want more fine-tune control over which users can use these features (since each request costs them money). As an example, they may have a single admin and two editors that should have access but none of the other admins or editors (or other account types). While we have settings in place to limit access based on role, that wouldn't help in this situation. So having some sort of override filter that allows you to have that level of control could be very useful and is something we do in a few other places, like within the I like the idea of introducing a new method to check if a user has access to the feature, that by default can have the checks we do right now (like checking the user role matches what is in the settings) but then has a filter around the final value, allowing someone total control on who can use the feature (this is just one potential approach though). For |
…ional features in the future if needed
@dkotter Thanks for the info! Does this look closer now to what you were thinking? I've added a Also, not sure if it's worth keeping the previous allowed_image_roles filters I added. Let me know if you think there would be of any value. Otherwise, I will update to remove them. |
* Filter the allowed WordPress roles for ChatGTP | ||
* | ||
* @since x.x.x | ||
* @hook classifai_chatgpt_allowed_image_roles |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this filter should have image
in it, I'm assuming this was probably just a copy/paste error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if ( | ||
! empty( $settings ) && | ||
isset( $settings['authenticated'] ) && | ||
false !== $settings['authenticated'] && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest we remove the authentication checks here.
- Seems to go against what this function says it does (checking if a user can access)
- And we recently introduced an
is_configured
method that does this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isset( $settings[ $feature ] ) && | ||
'no' !== $settings[ $feature ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar to the above, not sure I'd put this check here, was this checks if a feature is enabled, not if the user has access to the feature. I think I'd recommend removing this and instead adding our role checking in this method (which currently that hasn't been moved). So if we aren't authenticated or if the feature isn't turned on, no one will have access. But if both of those are true, we can then run this method to determine if an individual user should have access (by default, just checking if their role is allowed but developers can hook in and change access on a per user basis if needed).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -87,7 +124,7 @@ public function enqueue_editor_assets() { | |||
|
|||
if ( | |||
( ! empty( $excerpt_roles ) && empty( array_diff( $user_roles, $excerpt_roles ) ) ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned above, I'd move this check within the new user_can_access
method
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -87,7 +124,7 @@ public function enqueue_editor_assets() { | |||
|
|||
if ( | |||
( ! empty( $excerpt_roles ) && empty( array_diff( $user_roles, $excerpt_roles ) ) ) | |||
&& ( isset( $settings['enable_excerpt'] ) && 1 === (int) $settings['enable_excerpt'] ) | |||
&& $this->user_can_access( 'enable_excerpt', $excerpt_roles ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned above, I'd leave this enabled check alone rather than moving it into the new method
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -423,7 +473,7 @@ public function generate_excerpt( int $post_id = 0 ) { | |||
|
|||
// These checks (and the one above) happen in the REST permission_callback, | |||
// but we run them again here in case this method is called directly. | |||
if ( empty( $settings ) || ( isset( $settings['authenticated'] ) && false === $settings['authenticated'] ) || ( isset( $settings['enable_excerpt'] ) && 'no' === $settings['enable_excerpt'] ) ) { | |||
if ( ! $this->user_can_access( 'enable_excerpt' ) ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned above, if we remove auth checks and enabled checks from the user_can_access
method, I think these lines can stay as they are
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
&& ( ! empty( $roles ) && empty( array_diff( $user_roles, $roles ) ) ) | ||
&& ( isset( $settings['enable_image_gen'] ) && 1 === (int) $settings['enable_image_gen'] ) | ||
) { | ||
&& ( isset( $settings[ $feature ] ) && 1 === (int) $settings[ $feature ] ) ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar here, I'd move this enabled check out of this method
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition to some of the above comments, we have user role checking that happens in our REST endpoints which will need to be handled (check out the |
…ST API side as well
…ST API side as well
Description of the Change
Added filters to provide more granular control over new OpenAI features as outlined in #432
Closes #432
How to test the Change
Changelog Entry
Credits
Props @bjorn2404
Checklist: