Answers.Body: <p>One solution, that I have verified as working, is to check the .htaccess file in the root Drupal folder.</p>
  
  <p>As administrator, I would log in to the site, navigate to CiviCRM and find areas, such as price sets, profiles, even dashlets on the dashboard, were all coming up "access denied".</p>
  
  <p>It would occur after a major Drupal update. What was happening, was I was navigating into (example) <a href="http://www.drupal.com" rel="nofollow">http://www.drupal.com</a>, while the server was set up to <a href="http://drupal.com" rel="nofollow">http://drupal.com</a>.</p>
  
  <p>I could log in fine. But I would get the access denied issues. The reason is the Drupal update had overwritten my .htaccess file.</p>
  
  <p>So, for whatever set up you have, ensure that your .htaccess corresponds.</p>
  
  <p>From the .htaccess file, located in your root Drupal folder (use your server control panel, or an ftp client to see the file):</p>
  
  <pre><code>  # If your site can be accessed both with and without the 'www.' prefix, you
    # can use one of the following settings to redirect users to your preferred
    # URL, either WITH or WITHOUT the 'www.' prefix. Choose ONLY one option:
    #
    # To redirect all users to access the site WITH the 'www.' prefix,
    # (http://example.com/... will be redirected to http://www.example.com/...)
    # uncomment the following:
    # RewriteCond %{HTTP_HOST} .
    # RewriteCond %{HTTP_HOST} !^www\. [NC]
    # RewriteRule ^ http%{ENV:protossl}://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
    #
    # To redirect all users to access the site WITHOUT the 'www.' prefix,
    # (http://www.example.com/... will be redirected to http://example.com/...)
    # uncomment the following:
     RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
     RewriteRule ^ http%{ENV:protossl}://%1%{REQUEST_URI} [L,R=301]
  </code></pre>
  
  <p>Originally, the last two lines of the above .htaccess file were # out.</p>
  
  <ol>
  <li>I removed the #. </li>
  <li>Refreshed my browser.</li>
  <li>Re-logged in.</li>
  </ol>
  
  <p><strong>Result: all the "access denied" errors are gone.</strong></p>
  
  <p>You will have to select the correct option for your server settings.</p>
  
  <p>Hope it helps!</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-01T11:37:06.850Z
Answers.Text: Thanks for the hint. My htaccess seems ok - also, I noticed no 'access denied' on any other places then price set.
Answers.UserDisplayName: commonpike
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-30T20:23:50.113Z
Answers.LastActivityDate: 2015-09-30T20:23:50.113Z
Answers.UserDisplayName: CuriousGeorge
Answers.Body: <p>please have a look at </p>
  
  <p>Administer -> Users and Permissions -> Access Control -> Drupal Access Control </p>
  
  <p>you will find all the user access right available for the user  </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-15T13:22:48.260Z
Answers.Text: Yes, looked there, takes me to drupals ``admin/people/permissions``. For the admin user, everything is checked under the 'civicrm' tabs.
Answers.UserDisplayName: commonpike
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-15T13:37:12.767Z
Answers.Text: are you trying this in a Fresh copy - if not please try to disable all the CiviCRM extension and then Try to add the Priceset
Answers.UserDisplayName: Ramesh - ARTECH Consultancy
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-17T19:42:35.953Z
Answers.Text: No, no fresh copy. What sort of CiviCRM extensions should I disable ? This is a live site :-/
Answers.UserDisplayName: commonpike
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-18T08:19:48.240Z
Answers.Text: I tried the same against an Fresh Copy which worked alright - so just make a copy of your LIVE and create a test environment and then try it
Answers.UserDisplayName: Ramesh - ARTECH Consultancy
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-18T12:12:36.690Z
Answers.Text: I have no doubt it works if everything is allright :-) i also have no doubt it used to work in older versions, since there were hardly any bug reports about this. so yes, i could create a test environment, update everything and see if it magically fixes itself ... it would take a few hours. any other other suggestions are very welcome, too.
Answers.UserDisplayName: commonpike
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-15T13:09:11.813Z
Answers.LastActivityDate: 2015-09-15T13:09:11.813Z
Answers.UserDisplayName: Ramesh - ARTECH Consultancy
Answers.Body: <p>I had a similar problem (CiviCRM 4.6) and solved it as follows:</p>
  
  <p>The price sets kind of belong to the event component, and therefore they require not only "regular" CiviCRM permissions, but also access CiviEvent. Since the CiviEvent component wasn't enabled, the permissions weren't there, and the admin user didn't have them.</p>
  
  <p>After enabling CiviEvent and giving CiviEvent access (in Drupal) to the administrator role it worked.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-03T16:13:34.313Z
Answers.Text: there is also an open issue in the CiviCRM bug tracker to create an explicit permission for editing price sets: https://issues.civicrm.org/jira/browse/CRM-17615
Answers.UserDisplayName: sleidig
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-02-25T01:46:36.440Z
Answers.Text: Yep that works!
Answers.UserDisplayName: KarinG - Semper IT
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-10-11T17:40:51.783Z
Answers.Text: This is still true for CiviCRM 5.6.0. Interestingly, also in Drupal, enabling CiviEvent, giving permissions and disabling CiviEvent, also works. In case you don't want to have the CiviEvent menu around...
Answers.UserDisplayName: Javier Elices
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-29T16:17:26.277Z
Answers.LastActivityDate: 2016-01-29T16:17:26.277Z
Answers.UserDisplayName: Fabian
Body: <p>I have this problem</p>
  
  <p><a href="https://forum.civicrm.org/index.php?topic=36211.0" rel="nofollow">https://forum.civicrm.org/index.php?topic=36211.0</a></p>
  
  <p>'access denied' for administrator on the price set admin page</p>
  
  <pre><code>civicrm/admin/price?reset=1&amp;action=add
  </code></pre>
  
  <p>using civicrm 4.5.3 and drupal 7.33</p>
  
  <p>The 'access denied' screen is a drupal screen, not an apache error. The message shows up in the 'recent log messages'.</p>
  
  <p>Where should I start looking ?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-11-30T17:05:59.540Z
Comments.Text: @commonpike did you ever get to the bottom of this? I'm still stumped by it one one site. Checked through everything and can't see any obvious gotchas.
Comments.UserDisplayName: Graham
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-12-01T14:45:35.167Z
Comments.Text: nope, still stuck too
Comments.UserDisplayName: commonpike
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-12-30T18:27:36.557Z
Comments.Text: A little more on this @commonpike, in case it might help: on the site where I'm seeing this same issue I find that if I log in as a different user that also has the relevant privileges to be able to access the price sets pages, then I can access those pages without any difficulty.
Comments.UserDisplayName: Graham
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-08-03T21:40:27.213Z
Comments.Text: For the record, the now accepted answer solved this for me, the OP.
Comments.UserDisplayName: commonpike
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-09-15T13:25:03.090Z
Comments.Text: PS. Under ``admin/people/permissions`` everything is checked under the 'civicrm' tabs for the admin user.
Comments.UserDisplayName: commonpike
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-09-30T20:54:01.383Z
Comments.Text: when you move to the page with 'access denied' is anything changing with the url, eg https to http, or www to no www.
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-10-01T11:31:47.973Z
Comments.Text: @petedzn - no, the url stays 100% the same
Comments.UserDisplayName: commonpike
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-10-10T07:29:15.863Z
Comments.Text: I've just started seeing this on a site I'm working on. A colleague with exactly the same access privileges can access the price set page, but I get an 'access denied'.
Comments.UserDisplayName: Graham
Tags: <drupal><acl><price-sets>
Title: Access denied on price set page
ThreadText: # Access denied on price set page
  
  (Asked by: username_0 on 2015-09-15)
  
  I have this problem
  
  <https://forum.civicrm.org/index.php?topic=36211.0>
  
  'access denied' for administrator on the price set admin page
  
  ```
  civicrm/admin/price?reset=1&action=add
  
  ```
  
  using civicrm 4.5.3 and drupal 7.33
  
  The 'access denied' screen is a drupal screen, not an apache error. The message shows up in the 'recent log messages'.
  
  Where should I start looking ?
  
  **Tags:** drupal, acl, price-sets
  
  > **Comments:**
  > **username_0**: PS. Under ``admin/people/permissions`` everything is checked under the 'civicrm' tabs for the admin user.  
  > **username_2**: when you move to the page with 'access denied' is anything changing with the url, eg https to http, or www to no www.  
  > **username_0**: @petedzn - no, the url stays 100% the same  
  > **username_1**: I've just started seeing this on a site I'm working on. A colleague with exactly the same access privileges can access the price set page, but I get an 'access denied'.  
  > **username_1**: @username_0 did you ever get to the bottom of this? I'm still stumped by it one one site. Checked through everything and can't see any obvious gotchas.  
  > **username_0**: nope, still stuck too  
  > **username_1**: A little more on this @username_0, in case it might help: on the site where I'm seeing this same issue I find that if I log in as a different user that also has the relevant privileges to be able to access the price sets pages, then I can access those pages without any difficulty.  
  > **username_0**: For the record, the now accepted answer solved this for me, the OP.  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_5 on 2016-01-29. Score: 7 | Accepted answer
  
  I had a similar problem (CiviCRM 4.6) and solved it as follows:
  
  The price sets kind of belong to the event component, and therefore they require not only "regular" CiviCRM permissions, but also access CiviEvent. Since the CiviEvent component wasn't enabled, the permissions weren't there, and the admin user didn't have them.
  
  After enabling CiviEvent and giving CiviEvent access (in Drupal) to the administrator role it worked.
  
  > **Comments:**
  > **username_6**: there is also an open issue in the CiviCRM bug tracker to create an explicit permission for editing price sets: https://issues.civicrm.org/jira/browse/CRM-17615  
  > **username_7**: Yep that works!  
  > **username_8**: This is still true for CiviCRM 5.6.0. Interestingly, also in Drupal, enabling CiviEvent, giving permissions and disabling CiviEvent, also works. In case you don't want to have the CiviEvent menu around...  
  
  ---
  
  ### Answer by username_3 on 2015-09-30. Score: 1
  
  One solution, that I have verified as working, is to check the .htaccess file in the root Drupal folder.
  
  As administrator, I would log in to the site, navigate to CiviCRM and find areas, such as price sets, profiles, even dashlets on the dashboard, were all coming up "access denied".
  
  It would occur after a major Drupal update. What was happening, was I was navigating into (example) <http://www.drupal.com>, while the server was set up to <http://drupal.com>.
  
  I could log in fine. But I would get the access denied issues. The reason is the Drupal update had overwritten my .htaccess file.
  
  So, for whatever set up you have, ensure that your .htaccess corresponds.
  
  From the .htaccess file, located in your root Drupal folder (use your server control panel, or an ftp client to see the file):
  
  ```
    # If your site can be accessed both with and without the 'www.' prefix, you
    # can use one of the following settings to redirect users to your preferred
    # URL, either WITH or WITHOUT the 'www.' prefix. Choose ONLY one option:
    #
    # To redirect all users to access the site WITH the 'www.' prefix,
    # (http://example.com/... will be redirected to http://www.example.com/...)
    # uncomment the following:
    # RewriteCond %{HTTP_HOST} .
    # RewriteCond %{HTTP_HOST} !^www\. [NC]
    # RewriteRule ^ http%{ENV:protossl}://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
    #
    # To redirect all users to access the site WITHOUT the 'www.' prefix,
    # (http://www.example.com/... will be redirected to http://example.com/...)
    # uncomment the following:
     RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
     RewriteRule ^ http%{ENV:protossl}://%1%{REQUEST_URI} [L,R=301]
  
  ```
  
  Originally, the last two lines of the above .htaccess file were # out.
  
  1. I removed the #.
  2. Refreshed my browser.
  3. Re-logged in.
  
  **Result: all the "access denied" errors are gone.**
  
  You will have to select the correct option for your server settings.
  
  Hope it helps!
  
  > **Comments:**
  > **username_0**: Thanks for the hint. My htaccess seems ok - also, I noticed no 'access denied' on any other places then price set.  
  
  ---
  
  ### Answer by username_4 on 2015-09-15. Score: 0
  
  please have a look at
  
  Administer -> Users and Permissions -> Access Control -> Drupal Access Control
  
  you will find all the user access right available for the user
  
  > **Comments:**
  > **username_0**: Yes, looked there, takes me to drupals ``admin/people/permissions``. For the admin user, everything is checked under the 'civicrm' tabs.  
  > **username_4**: are you trying this in a Fresh copy - if not please try to disable all the CiviCRM extension and then Try to add the Priceset  
  > **username_0**: No, no fresh copy. What sort of CiviCRM extensions should I disable ? This is a live site :-/  
  > **username_4**: I tried the same against an Fresh Copy which worked alright - so just make a copy of your LIVE and create a test environment and then try it  
  > **username_0**: I have no doubt it works if everything is allright :-) i also have no doubt it used to work in older versions, since there were hardly any bug reports about this. so yes, i could create a test environment, update everything and see if it magically fixes itself ... it would take a few hours. any other other suggestions are very welcome, too.  
  
  ---
  
  