Answers.Body: <p>The only point of those permissions is to determine whether the user has access to the plugins’ sections, so it would be pretty pointless to show the permissions for plugins that don’t have sections.</p>
  
  <p>The confusion here is probably just in the wording of the permissions. “Access [Plugin]” isn’t very clear on which aspect of the plugin you’re granting access to. So maybe we should change that to “Access [Plugin]’s CP section” or something.</p>
  
  <p>If you have a plugin that offers functionality that warrants user permissions, register your own custom user permissions using the <a href="https://docs.craftcms.com/v2/plugins/hooks-reference.html#registeruserpermissions" rel="nofollow noreferrer">registerUserPermissions hook</a>, and verify that the user has those permissions using <a href="http://buildwithcraft.com/classreference/services/UserSessionService#checkPermission-detail" rel="nofollow noreferrer">craft()->userSession->checkPermission()</a>.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-27T09:26:26.097Z
Answers.Text: I guess that requires giving the controller methods anonymous access, then adding auth checks inside those methods? I was hoping for some sort of built-in middle ground, to allow for user groups to be given access; such as through using a different method to determine if the plugin should be listed on the permissions screen - or perhaps just a new method of hasCPTab or similar, which is used when drawing the CP navigation options? (so 2 methods in the plugin class - one for permissions, one for having nav entry). hasCPTab could be assumed to be true, unless method exists and returning false?
Answers.UserDisplayName: Tom
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-27T13:49:15.037Z
Answers.Text: But then we’d be leaving it up to the plugin developer to enforce those permissions, however they choose to. Not going to happen; I don’t want to add permissions that don’t have a specific intended purpose.
Answers.UserDisplayName: Brandon Kelly
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2015-08-26T22:41:31.933Z
Answers.LastActivityDate: 2018-10-09T16:01:34.963Z
Answers.LastEditDate: 2018-10-09T16:01:34.963Z
Answers.UserDisplayName: Brandon Kelly
Body: <p>A user group cannot be given access to a plugin without the plugin having hasCpSection.</p>
  
  <p>I don't want to give anonymous access to the plugin's methods; is there not an option to have a plugin listed for user group permission allocation without it having an cp tab? Too many cp tabs cause a JS error - but that's another issue...</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-08-25T17:13:38.647Z
Comments.Text: This sounds like a bug. Whether or not a plugin has a tab should be completely irrelevant to whether a user group has permission to access it. I'd recommend reporting this bug directly to support@buildwithcraft.com
Comments.UserDisplayName: Lindsey D
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-08-25T18:00:38.287Z
Comments.Text: Hey Tom... trying to decide if this is a bug or a feature request. Are you saying that they can't load any plugin pages in the CP?  Or they can't post to a plugin's controller action? Feel free to send the plugin over to support@buildwithcraft.com along with steps to reproduce and we can update here with any results.
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-08-26T10:02:09.040Z
Comments.Text: @BradBell If a plugin does not have hasCpSection, it is not listed under the plugins section when assigning permissions. Without this, that user cannot access anything the plugin has - e.g. controllers actions (which makes sense). Tying the ability to define permissions for plugins based on hasCpSection doesn't. I've tried adding the db table row entries for a plugin for a user group - they get over-written the next time the user group permissions are saved (because they're not in the permissions plugins list, as they don't have hasCpSection...) Seems like a lot of assumptions on hasCpSection?
Comments.UserDisplayName: Tom
Tags: <plugin-development><permissions>
Title: Cannot grant user group plugin permission without hasCpSection
ThreadText: # Cannot grant user group plugin permission without hasCpSection
  
  (Asked by: username_0 on 2015-08-25)
  
  A user group cannot be given access to a plugin without the plugin having hasCpSection.
  
  I don't want to give anonymous access to the plugin's methods; is there not an option to have a plugin listed for user group permission allocation without it having an cp tab? Too many cp tabs cause a JS error - but that's another issue...
  
  **Tags:** plugin-development, permissions
  
  > **Comments:**
  > **username_1**: This sounds like a bug. Whether or not a plugin has a tab should be completely irrelevant to whether a user group has permission to access it. I'd recommend reporting this bug directly to support@buildwithcraft.com  
  > **username_2**: Hey Tom... trying to decide if this is a bug or a feature request. Are you saying that they can't load any plugin pages in the CP?  Or they can't post to a plugin's controller action? Feel free to send the plugin over to support@buildwithcraft.com along with steps to reproduce and we can update here with any results.  
  > **username_0**: @username_2 If a plugin does not have hasCpSection, it is not listed under the plugins section when assigning permissions. Without this, that user cannot access anything the plugin has - e.g. controllers actions (which makes sense). Tying the ability to define permissions for plugins based on hasCpSection doesn't. I've tried adding the db table row entries for a plugin for a user group - they get over-written the next time the user group permissions are saved (because they're not in the permissions plugins list, as they don't have hasCpSection...) Seems like a lot of assumptions on hasCpSection?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_3 on 2015-08-26. Score: 2
  
  The only point of those permissions is to determine whether the user has access to the plugins’ sections, so it would be pretty pointless to show the permissions for plugins that don’t have sections.
  
  The confusion here is probably just in the wording of the permissions. “Access [Plugin]” isn’t very clear on which aspect of the plugin you’re granting access to. So maybe we should change that to “Access [Plugin]’s CP section” or something.
  
  If you have a plugin that offers functionality that warrants user permissions, register your own custom user permissions using the [registerUserPermissions hook](https://docs.craftcms.com/v2/plugins/hooks-reference.html#registeruserpermissions), and verify that the user has those permissions using [craft()->userSession->checkPermission()](http://buildwithcraft.com/classreference/services/UserSessionService#checkPermission-detail).
  
  > **Comments:**
  > **username_0**: I guess that requires giving the controller methods anonymous access, then adding auth checks inside those methods? I was hoping for some sort of built-in middle ground, to allow for user groups to be given access; such as through using a different method to determine if the plugin should be listed on the permissions screen - or perhaps just a new method of hasCPTab or similar, which is used when drawing the CP navigation options? (so 2 methods in the plugin class - one for permissions, one for having nav entry). hasCPTab could be assumed to be true, unless method exists and returning false?  
  > **username_3**: But then we’d be leaving it up to the plugin developer to enforce those permissions, however they choose to. Not going to happen; I don’t want to add permissions that don’t have a specific intended purpose.  
  
  ---
  
  