Permissions for Patents and Proposals?

[khuffman]

In our set up of er-core, any person logged in (faculty,student etc.) is able to view content types such as "Patents" or "Proposals or Grants" created by other people. So when a faculty who logs in, can go to "Content" list and click on a Proposal/Grants and view another faculty's proposals. Does your er-core set up behave the same way? If not, can you please share with us what have you done to restrict access to certain content types? (Note this question is not about the permission to patent or proposal view that is used in the Accomplishment Table, see https://github.com/EPSCoR/ERCore-3.0/issues/10 )

Ideally I would like to restrict access to viewing/editing "Patents" or "Proposals or Grants" to only content creator and "Administrative Staff" role. I have been looking at PageManager, and will try to see if I can get something working. Thanks for any tips, ideas. Also we noticed that in our er-core setup that the content types "Patents" or "Proposals or Grants" have in their the publishing option the "Promote to front page" checked. We unchecked that because we do not want those content types shown on the front page (but this is not really a solution for our above problem).

[cjallen-epscor]

@khuffman

at */admin/people/permissions you can adjust as needed by Content Type (patents, propoals/grants) and restrict what role gets to see what.

[cjallen-epscor]

Re: your second issue; that was what I proposed - I had a card for this pesky "Promote to Front page" and addressed it here - https://github.com/EPSCoR/ERCore-3.0/issues/5

[aturling]

When we installed ER Core, grants/proposals were hidden from all but admin and admin staff under the view permissions at /admin/structure/views/view/er_summary_er_proposal/edit We decided to leave these permissions and added a note to the Accomplishments page (next to the "Grant/Proposal counts include all grants regardless of status" text) that only admins can view proposals due to the sensitive nature of the content (to explain why people were seeing "access denied" when they clicked that link).

[khuffman]

Chris, I know about the permission table but in this case it isn't helping me. Sorry I'm not explaining this correctly, let me try again:

• Faculty A (has role "faculty") logs and in enters a Proposal & Grant (or a Patent) then save it.
• Faculty B (has role "faculty") who has no connection to Faculty A, logs in and clicks on "Content" in the top black bar and now gets to see a table with a list of recently added content.

-Faculty B sees the entry that Faculty A just entered. So being curious, Faculty B clicks the title and it takes him to the view page of the Proposal that Faculty A entered.

Please try it on your site, and let me know if this is how it works on your site too?

In the permission page I have tried the limit who can see the list of "Content" (but faculty B can still guess the node number and just enter the URL of the page and he will get to see the Proposal that Faculty A entered). So hiding the Content list is not a fool proof solution.

I want a solution that if a person clicks the link in the Content table that the only people who can see the proposal are the person who created the proposal, or Administrative Staff role.

Kia

On 04/16/2015 10:50 AM, Chris Allen wrote:

Kia -

at */admin/people/permissions you can adjust as needed by Content Type (patents, propoals/grants) and restrict what role gets to see what.

— Reply to this email directly or view it on GitHub https://github.com/EPSCoR/ERCore-3.0/issues/14#issuecomment-93753720.

[ercore]

Kia,

On our live site we don't even give our faculty access to the Content table. They can only add content and see their related content on their user profile page. Perhaps this could be an option for you?

See attached screenshot of what a faculty user can see.

Isis Serna Website Administrator EPSCoR | DataONE | UNM 1312 Basehart SE Albuquerque, NM 87106 Phone: 505.814.7599

On Apr 16, 2015, at 9:22 AM, Kia Huffman notifications@github.com wrote:

Chris, I know about the permission table but in this case it isn't helping me. Sorry I'm not explaining this correctly, let me try again:

• Faculty A (has role "faculty") logs and in enters a Proposal & Grant (or a Patent) then save it.
• Faculty B (has role "faculty") who has no connection to Faculty A, logs in and clicks on "Content" in the top black bar and now gets to see a table with a list of recently added content.

-Faculty B sees the entry that Faculty A just entered. So being curious, Faculty B clicks the title and it takes him to the view page of the Proposal that Faculty A entered.

Please try it on your site, and let me know if this is how it works on your site too?

In the permission page I have tried the limit who can see the list of "Content" (but faculty B can still guess the node number and just enter the URL of the page and he will get to see the Proposal that Faculty A entered). So hiding the Content list is not a fool proof solution.

I want a solution that if a person clicks the link in the Content table that the only people who can see the proposal are the person who created the proposal, or Administrative Staff role.

Kia

On 04/16/2015 10:50 AM, Chris Allen wrote:

Kia -

at */admin/people/permissions you can adjust as needed by Content Type (patents, propoals/grants) and restrict what role gets to see what.

— Reply to this email directly or view it on GitHub https://github.com/EPSCoR/ERCore-3.0/issues/14#issuecomment-93753720.

— Reply to this email directly or view it on GitHub.

[khuffman]

So if a faculty logs in and then can guess the nodeID* of a content then on your site it will show the other person's proposal to this person who guessed the nodeID right? so you don't get "Access Denied" error.

(or uses the search box and enters the title of some proposal? or have disabled searching for non-admin staff?)

Kia

On 04/16/2015 11:42 AM, NM EPSCoR Reporting wrote:

Kia,

On our live site we don't even give our faculty access to the Content table. They can only add content and see their related content on their user profile page. Perhaps this could be an option for you?

See attached screenshot of what a faculty user can see.

Isis Serna Website Administrator EPSCoR | DataONE | UNM 1312 Basehart SE Albuquerque, NM 87106 Phone: 505.814.7599

On Apr 16, 2015, at 9:22 AM, Kia Huffman notifications@github.com wrote:

Chris, I know about the permission table but in this case it isn't helping me. Sorry I'm not explaining this correctly, let me try again:

• Faculty A (has role "faculty") logs and in enters a Proposal & Grant (or a Patent) then save it.
• Faculty B (has role "faculty") who has no connection to Faculty A, logs in and clicks on "Content" in the top black bar and now gets to see a table with a list of recently added content.

-Faculty B sees the entry that Faculty A just entered. So being curious, Faculty B clicks the title and it takes him to the view page of the Proposal that Faculty A entered.

Please try it on your site, and let me know if this is how it works on your site too?

In the permission page I have tried the limit who can see the list of "Content" (but faculty B can still guess the node number and just enter the URL of the page and he will get to see the Proposal that Faculty A entered). So hiding the Content list is not a fool proof solution.

I want a solution that if a person clicks the link in the Content table that the only people who can see the proposal are the person who created the proposal, or Administrative Staff role.

Kia

On 04/16/2015 10:50 AM, Chris Allen wrote:

Kia -

at */admin/people/permissions you can adjust as needed by Content Type (patents, propoals/grants) and restrict what role gets to see what.

— Reply to this email directly or view it on GitHub https://github.com/EPSCoR/ERCore-3.0/issues/14#issuecomment-93753720.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/EPSCoR/ERCore-3.0/issues/14#issuecomment-93767221.

[ercore]

They do not have access to a search field and I think it is highly unlikely that they can guess the nodeID for content that they did not create let alone content they did create. Have your users been doing this?

I do believe that if they do get to a page that they did not create it will give them an access denied error. This is what we have put in place on the Drupal users permissions.

Isis Serna Website Administrator EPSCoR | DataONE | UNM 1312 Basehart SE Albuquerque, NM 87106 Phone: 505.814.7599

On Apr 16, 2015, at 9:58 AM, Kia Huffman notifications@github.com wrote:

So if a faculty logs in and then can guess the nodeID* of a content then on your site it will show the other person's proposal to this person who guessed the nodeID right? so you don't get "Access Denied" error.

(or uses the search box and enters the title of some proposal? or have disabled searching for non-admin staff?)

Kia

On 04/16/2015 11:42 AM, NM EPSCoR Reporting wrote:

Kia,

On our live site we don't even give our faculty access to the Content table. They can only add content and see their related content on their user profile page. Perhaps this could be an option for you?

See attached screenshot of what a faculty user can see.

Isis Serna Website Administrator EPSCoR | DataONE | UNM 1312 Basehart SE Albuquerque, NM 87106 Phone: 505.814.7599

On Apr 16, 2015, at 9:22 AM, Kia Huffman notifications@github.com wrote:

Chris, I know about the permission table but in this case it isn't helping me. Sorry I'm not explaining this correctly, let me try again:

• Faculty A (has role "faculty") logs and in enters a Proposal & Grant (or a Patent) then save it.
• Faculty B (has role "faculty") who has no connection to Faculty A, logs in and clicks on "Content" in the top black bar and now gets to see a table with a list of recently added content.

-Faculty B sees the entry that Faculty A just entered. So being curious, Faculty B clicks the title and it takes him to the view page of the Proposal that Faculty A entered.

Please try it on your site, and let me know if this is how it works on your site too?

In the permission page I have tried the limit who can see the list of "Content" (but faculty B can still guess the node number and just enter the URL of the page and he will get to see the Proposal that Faculty A entered). So hiding the Content list is not a fool proof solution.

I want a solution that if a person clicks the link in the Content table that the only people who can see the proposal are the person who created the proposal, or Administrative Staff role.

Kia

On 04/16/2015 10:50 AM, Chris Allen wrote:

Kia -

at */admin/people/permissions you can adjust as needed by Content Type (patents, propoals/grants) and restrict what role gets to see what.

— Reply to this email directly or view it on GitHub https://github.com/EPSCoR/ERCore-3.0/issues/14#issuecomment-93753720.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/EPSCoR/ERCore-3.0/issues/14#issuecomment-93767221.

— Reply to this email directly or view it on GitHub.

[aturling]

In our version we hide the "Content" menu at the top for anyone who isn't admin/admin staff. This was done through Structure -> Menus -> Management, click and scroll down to "Content", edit permissions. This also prevents people from viewing the page if they type in directly "admin/content". We also hid the "EPSCoR" and "help" menus this way. Actually we hid all of the menus except for the little house icon that goes to the home page. (The "add content" link permissions are set through the navigation menu, not the management menu.) I don't know if there's a way to hide house icon -> index through the GUI but I added this code to one of my modules to hide it from non admin/admin staff users (not sure where it would go in ER core code):

function _admin_menu_output_alter(&$content) { if (!user_access('administer er')) { unset($content['menu']['admin/index']); } }

The reason for hiding "add content" from the black menu at the top was that if you click on that link, which goes to node/add, it has all of the content types (including basic page and article which most users shouldn't be accessing) with the default descriptions. But we've added a custom "add content" page that looks almost the same as node/add but with article and basic page removed and custom descriptions added to the content types. We also added a "user guide" page where we took the ER core default guide and customized it for our site, so that replaced the "help" menu option.

We hid the search block and set the permissions on the people -> permissions page to prevent non admin/admin staff users from using the search.

But I did just test and it is possible for a non admin user to see a proposal if they know the direct URL. I'm not sure how to fix that while keeping the accomplishments page open to all logged in users.

[aturling]

Sorry I should have hit preview first, the code got messed up:

function <insertmodulenamehere>_admin_menu_output_alter(&$content)
{
  if (!user_access('administer er'))
  {
    unset($content['menu']['admin/index']);
  }
}

[cjallen-epscor]

I found a solution and implemented on my turnkey locally.

It's the Content Access Module - https://www.drupal.org/project/content_access

I created "Some Proposal" and configured the Proposal Content type under the tab "Access Control" and unticked 'view any er_proposal content' for anonymous.

I then went to the page of the proposal logged out of course - http://localhost:8889/turnkey2015/drupal/content/some-proposal and got the message to the right.

I then logged in as a user with role of Faculty and got the same access denied error due to that user being a Faculty (does not have permission to view er_proposal content).

[aturling]

What about when a user looks at another user's profile? The proposals are listed under "Related Content" (but only title, not status). That would be a way for users to find the proposal titles and click on them even if they don't have access to the site-wide content page. Would this module hide that section of the user profile (for everyone other than the currently logged in user)? If not, is that a concern that others can see the proposal titles?

You could change the permissions for the Proposals attachment under the er_related_content view to admin/admin staff but then users wouldn't be able to see their own proposals and wouldn't be able to edit them (unless they had the url in their browser history).

[iserna]

I do believe you can get more specific with permissions. I don't foresee users looking at other users profiles unless you have Administrative privileges. If a user has been tagged in a proposal it will be displayed in their related content, on their user profile. And they should be able to see it, maybe not edit it, because they were tagged in it.

I also need to note that the Content page/view is a Drupal Core view and not an ER Core view. This is why we simply do not make it accessible to Faculty and Students.

Also, Kia noticed something yesterday on our live site. She guessed a node id and was able to see the content on that page, as an Anonymous viewer on our reporting site. I checked our Drupal role permissions and edited this line on the Drupal Permissions GUI,

/admin/people/permissions Node

View published content > Uncheck Anonymous User and Authenticated User

This is a simple configuration to disable Anonymous Users from being able to view any content on you site even if they guess the node id.

-Isis

[aturling]

Are the permissions to view user profiles = admin only set in ER core by default? It's possible that we changed the permissions for profiles at one point, but user profiles have always (that I can remember) been open to all authenticated users (with certain fields having additional restrictions, like those under the demographics tab). I see that it can be set under permissions -> user -> view user profiles.

I did find a way to make proposals appear on the logged in user's profile but not on profiles of other users: edit the er_related_content view, click on proposals PI/Co-PI attachment, add an additional contextual filter for PI/Co-PI -> use default value -> currently logged in user. Do the same for the proposals - other EPSCoR researcher attachment (add additional contextual filter for "Other EPSCoR Researcher"). Then you can only see proposals under "Related Content" if you're tagged in the proposal somehow (as PI/Co-PI/researcher) AND you're the currently logged in user. So let's say I'm PI/Co-PI (or "Other EPSCoR researcher") on Proposal A. If I click on my user profile, Proposal A shows up. If someone else clicks on my profile, Proposal A does not appear.

Thanks for pointing out the "View published content" permissions fix - ours had "Anonymous User" checked too so I unchecked it. It'd probably be good to add a bullet point on the view published content permissions in the installation guide here: http://epscorreporting.com/installation-guide#toc-Subsubsection--5

[iserna]

Yes, it should either be noted in the installation guide to uncheck these options or it may be better to adjust the default settings in the default core to already have them unchecked.

I need to review in more detail your find for proposals.

[cjallen-epscor]

I noticed too that the permissions for "View Published Content" is set for Anonymous.

There are several views that use that "View Published Content"; which is not good.

I propose we make this in core so that only those users with an account ('Authenticated' user) are able to "View Published Content".

[aturling]

I think that would be a good default value for "view published content." One downside to this is that I think it affects all Drupal nodes, not just ER-related nodes. For example, we had a "Getting Started" basic page with instructions for new users, but with the view published content setting turned off for anonymous users, they now see "access denied" (so I removed the page). You can get around it by using blocks instead of pages - our "Welcome to the Missouri EPSCoR reporting site" on the front page is a block so it's still visible to anonymous users. It's not a big deal for us because anonymous users don't need to see more than the "welcome" block and login form; we've been e-mailing registration instructions to everyone anyway.

This would require another update to the installation guide here: http://epscorreporting.com/installation-guide#toc-Section-10

Namely the instructions for creating a "Welcome to EPSCoR Reporting" page would have to change because under the new default permission settings, only logged in users would see the welcome page.

[aturling]

I just added the branch 3.1.1-nodeaccess. This adds a node_access function to er.module that restricts access to all proposals. If a user is a PI/Co-PI, "other researcher" (as listed on the proposal), or a site admin, that user may view the proposal - all other users see "access denied."

Related to this, I made the following changes to the er_related_content view:

On the Proposals (PI/Co-PI) attachment: I added a second contextual filter, so there are now two:

1. Content: EPSCoR PI/Co-PI (field_er_epscor_pi_co_pi) Provide default value -> User ID from URL
2. Content: EPSCoR PI/Co-PI (field_er_epscor_pi_co_pi) Provide default value -> User ID from logged in user

Similarly--- On the Proposals (other) attachment: I added a second contextual filter, so there are now two:

1. Content: EPSCoR Researcher(s) (field_er_user_entity_reference) Provide default value -> User ID from URL
2. Content: EPSCoR Researcher(s) (field_er_user_entity_reference) Provide default value -> User ID from logged in user

The first filter grabs all of the proposals where the user (from the URL) is a PI or Co-PI (this filter is already in ER Core). But, for example, any user could visit:

http://dev-ercore.nmepscor.net/users/jfrost

and see the titles of all of that user’s submitted proposals. Even though the new code in er.module would show "access denied" if a non-admin user not affiliated with the grant tried to click the link - I still think it's better not to show the titles at all if you don't have access to the proposal.

So the second filter grabs all of the proposals where the currently logged in user is listed as a PI/Co-PI or EPSCoR researcher. Together, these two filters make it so that jack frost can visit his page at /user and see all of his proposals, but when anyone else visits http://dev-ercore.nmepscor.net/users/jfrost, they don’t see jack's proposals (unless they're collaborating with jack on a proposal). The downside is that this hides the proposals on the related content pane from admins, but admins can see the proposals everywhere else on the site (including the team view since the proposal pane is restricted to admins only).

Another solution is to restrict the proposal attachments to admin only in the view permissions, but then users wouldn't be able to see their own proposals to edit them. So the above is a bit more complicated but I like that it allows users to see their own proposals but hides the titles and links from others.

So far I've only implemented the access restrictions for proposals, but you could do the same thing with patents.