New to the community? Start here

[Integrated Video Tutorials] IVT Viewer Permissions by Capability

0

I understand that IVT > Settings > Permissions is for plugin admins. This request is to add User/Viewer Permissions.

User Permissions should be based on Capability, not Role. This way we can link video viewing access to membership, subscriptions, and other non-admin guest access.

The current settings page for Permissions says:

> User Permissions
> Configure which user roles can access and configure plugin’s settings.

I see this has caused some confusion which is easily remedied by changing the word ‘User’ to ‘Management’. The Roles are for video management.

The text “Choose which user roles…” fits common WP usage so personally I think that shouldn’t change.

With that section clearly recognized as Management Permissions and Management Roles, the new section I propose for actual User Permissions becomes very clear in its purpose.

Actually, we tend to over-Use the term User, and a better term here might be Viewer.

In summary: In the Permissions page I propose changing User Permissions to Management Permissions, User Roles to Management Roles, and adding a Viewer Permissions section.

Side notes:

Frankly, our friends in DEV development often confuse Roles with Capabilities. We see a lot of features and access based on a hard-coded “manage_options” capability, where specific capabilities should be created to support specific features.

The permissions to maintain videos should be based on Capabilities as well, not role.
Someone who has access to video maintenance should not by default have access to text/content like an Editor.
Similarly, someone who has the ability to contribute content should not have the ability to modify site videos.
And we should not need to create a special Role for Video Manager.
If permissions here were based on capability, then we could assign that capability to whatever roles we wish.

I won’t ask in this request for the Management Permissions area to be changed to being Capability-based, but the ability to assign permissions based on role AND capabilities should be a part of all permissions settings for all plugins.

Please don’t make capability selection based on a dropdown or checkboxes. If configuration settings are moved to a different system, it might not yet have the same capabilities configured and this UI shouldn’t concern itself with “role or capability doesn’t exist” conditions. Just let us enter what we want, perhaps in a text area in addition to the option to use limited checks and dropdowns, and we’ll manage the details elsewhere of whether or not those permissions exist. Don’t make us do something elsewhere before we come back to these config settings – that might not work with our workflow at that moment and it serves no practical purpose to force the situation on us. I feel the same about role selection checkboxes but am not asking for any changes.

With my ongoing mantra of liberally adding and documenting hooks in these plugins, I really wish DEV would create and document access hooks in all places that permissions are checked, so that we can ignore the entry-level UI settings and control access more rigorously in code. Really, this is very easy: Just add filter hooks as a regular part of development, and point us to them in docs and forum support, and it won’t be necessary to put requests on forever-hold because there are no resources to allocate to make big UI changes.

Thanks.

Tue, 23 Aug 2022 20:22:52
More Integrated Video Tutorials discussions
Integrated Video Tutorials
  • Nithin Ramdas
    • Support Wizard

    Hi Tony G ,

    I have passed your observations regarding this to our team’s attention so that they could check its scope and see whether it could be looked at in future updates.

    With my ongoing mantra of liberally adding and documenting hooks in these plugins, I really wish DEV would create and document access hooks in all places that permissions are checked, so that we can ignore the entry-level UI settings and control access more rigorously in code. Really, this is very easy: Just add filter hooks as a regular part of development, and point us to them in docs and forum support, and it won’t be necessary to put requests on forever-hold because there are no resources to allocate to make big UI changes.

    The idea would be to provide members with fewer options in terms of coding and provide options via UI to make changes. As that is what’s mostly preferred by our members.

    Any examples or use cases you could provide on what you are looking to ignore in terms of UI settings in IVT plugin? Is it only specific to the capabilities or permissions as stated? or you mean with every settings?

    Thanks for your feedback. We really appreciate it.

    Kind Regards,
    Nithin

  • Tony G
    • Mr. LetsFixTheWorld

    Thank you Nithin .

    The idea would be to provide members with fewer options in terms of coding and provide options via UI to make changes. As that is what’s mostly preferred by our members.

    Yes, great idea in principle but severely flawed in practice. Years goes by with these plugins and we don’t see UI options like that. I’m not complaining. I’m citing an accepted fact of life, a completely valid business scenario where demand is lacking and funds for pro-active development are insufficient and priorized elsewhere.

    That condition leaves us all without many features that some of us could have with code. That is, right now we often get no solution for everyone where with code we can often get some solution for many of us. And with a nurtured ecosystem of developers to build on the WPMU DEV platform, we could actually get a lot of solutions for most of us at almost zero cost to the company. DEV can look like heroes without the expense. That doesn’t seem to be a vision that you folks share, though it is the foundation of WordPress itself and all other FOSS. You guys insist on being the cathedral in the middle of the bazaar. To me, that’s just bizarre.

    That’s why I frequently suggest hooks rather than asking for features, and I encourage my fellow member/clients to do the same. The response today for many requests is ultimately “this won’t happen in our lifetimes”, in the form of a very courteous “we’ll pass this to the developers”. With hooks in the code, the response can always be “we don’t have the feature, yet, but until we do, you can get the feature you want now with this code”. The response, especially with software, and especially with FOSS, should always be “yes, and here is how we do this”.

    Code is not a menace to be avoided at all costs. It’s the perfect option in the world of Free and Open Source Software, where we have the liberty to do exactly these things. Code integrations should not be discouraged. They should be encouraged, because that’s how FOSS works and grows more useful.

  • Tony G
    • Mr. LetsFixTheWorld

    On topic with this thread… The following is focused on capabilities, roles, and hooks to check for permissions for specific features.

    Even if not used by the audience who is supposedly “UI only”, hooks for function permissions would respond to many requests in these forums for all DEV plugins. I haven’t looked recently but in the past most DEV functionality is based on a simple test for capability ‘manage_options’. That is, if the current use has Administrator role, they can do anything with any DEV plugin. The role selection options in IVT are awesome and should be implemented elsewhere.

    It’s important for DEV to understand that your plugins are not all in the same category, and the solutions for one are not good for all. DEV produces “applications” in addition to “utilities”. For example:
    – Defender is a utility for system administration – ‘manage_options’ is a fine first choice for all features in this plugin.
    – But Forminator is an application related to content. Forminator might best be administered by someone in a Marketing role, someone who might not have anything to do with the website in terms of posts and pages. So they wouldn’t need a role like Editor or Contributor. They need a role like Marketing that has a capability like ‘forminator_admin’.
    – Smush is a utility for site internals. ‘manage_options’ is OK here. But do we need to give the person changing image compression the rights to delete plugins? No, Smush features should be capability driven, like ‘smush_admin’.
    – Hustle is an application related to marketing. Do we want to give someone who manages a visitor conversion campaign the rights to disable backups. As above, if ‘manage_options’ is required to administer Hustle then that’s the scenario we all have right now. It would be much better to have a ‘hustle_admin’ capability.

    It would be better for all DEV plugins, and features within them, to be based on specific capabilities. That is, “does this user have permission to use this feature?” Roles are bundles of related capabilities. A role is a friendly-named reference to a group of techie-oriented capability IDs. A single user can have multiple roles ( see “WP_User->add_role()” ). For example, anyone logged-in can be a “Subscriber”, but some Subscribers might be Appointment Creators, or Customers, or Video Consumers. Some Video Consumers might have permission to create playlists, others not. Some Video Consumers might have limited ability to create playlists, like a max of 10. Some Marketing staff might have the ‘hustle_admin’ capability, and others might have ‘forminator_admin’. And a site might want to have a SiteAdmin role that can administer Defender and Branda and SmartCrawl, but not Hustle, not Forminator, and maybe not even permission to create posts or pages.

    I would never ask WPMU DEV for complex role or capability management for any plugin. But I do ask for the ability to decide when a user has access to a feature, rather than you folks making that decision, and occasionally not doing so well with that decision. For example, with IVT, the main topic here…

    Can the current user see a specific playlist?
    Can the current user modify a specific playlist?
    Can the current user see other playlists?
    Can the current user modify all playlists?
    Can the current user modify the visibility of playlists for other users?

    DEV doesn’t need to add a UI to respond to all of these questions (and yes, some of this functionality IS already in there). Consider prefacing all functionality with something like:

    
if(! apply_filters('wpmudev_can', user_can($user->ID, 'cap_name'),'cap_name'))
  return;

    We can still add specific capabilities to existing roles if we wish, or create new roles – that’s how it works now. But with that kind of code we can collaborate to decide based on the capability, independent of role, if the user can do something. There shouldn’t be an all-or-nothing permission, especially when a component has a front-end component.

  • Tony G
    • Mr. LetsFixTheWorld

    About use cases…

    I know we all need to justify efforts with a use case, especially when it comes to justification of expense for profit.

    The point in everything above is not about “Any examples or use cases you could provide on what you are looking to ignore in terms of UI settings in IVT plugin?”

    The point is: With individual capabilities for specific features, we don’t need new UI settings related to permissions, for any DEV plugins, and we open a Lot of use cases that simply aren’t possible now. With hooks on capabilities, sites with any unique use case can use this software without special requests, or code changes (which may never come) from WPMU DEV.

    To answer your question though, here’s a huge use case for you… When I look at IVT, I’m not seeing a plugin to display WordPress videos to WordPress users. I’m seeing a platform for user-defined playlists that’s better than the crap that YouTube offers. I could easily see this offered as an application of its own via SaaS. I know I’m not the first or only person who sees this. But I’d like to be one of the first to capitalize on it. (Too late now?) :)

    It’s fine if no one there shares such a vision. Just please stop limiting your software to use cases that you see yourselves. That’s an extremely short-sighted perspective that I’ve commented on before. The company mindset started to change on this when you shifted in great part from providing plugins to providing more complete services so that hosts can sell services to end-user/consumers. There’s so much more that can be done toward that goal, if only you’d think of your plugins more as being extensible tools than final solutions. You don’t know everything about the audience who will be using these tools – and neither do we. Let the industry find and solve problems, you just need to provide versatile tools, not tools that only solve specific problems. We gotta stop this process where we bring new use cases to you and you decide how you think changes can target those new use cases. That’s a silly, time consuming, costly process – and you guys often get it wrong. Ick. Stop that.

    Um, like I’m stopping now. Thanks.