Opened 6 years ago

Closed 6 years ago

#2075 closed task (fixed)

Handling roles

Reported by: cvvergara Owned by: webcom@…
Priority: normal Milestone: Unplanned
Component: WebSite Keywords:
Cc:

Description

The website has different roles.

The default role when a person gets registered is: subscriber

Besides the capability of "Read" I think can modify his own member page. (not sure, someone has to test)

How are we going to assign the different roles? Are they going to send a mail to SAC? open a ticket? when they request a role change?

Maybe if they belong to a project, they request the role change to the project's responsible persons for changing roles?

Change History (11)

comment:1 by robe, 6 years ago

We can change the default though. When I setup LDAP, it allowed me to change the default role of a person registered via LDAP. Since we are only allowing LDAPs (no more allowing registration on the website) and grandfathered accounts to log in, it's way more vetted than having some random user off the internet registering on the website. So we can be less cautious.

Some pages clearly need admin roles like Sponsors page. I'm not sure people are that concerned about an LDAP user defacing a project page for example, so not sure those need to be protected as much.

There is also the possibility of controlling role based on LDAP groups, I'm not sure the WPAuthDir has that out of the box, but I don't think it would be too hard to extend it if it doesn't or have a sideline PHP script that does the job.

comment:2 by jive, 6 years ago

Okay, I think that will make this initial roll out easier. And as you say we can mark some pages (sponsorship, committees) as requiring additional access.

comment:3 by robe, 6 years ago

forgot to mention I had already changed this cause too many people coming to me saying they couldn't edit. I'm not sure even subscriber gives you much control over your user page.

So default right now is editor.

comment:4 by robe, 6 years ago

I switched default back to subscriber.

comment:5 by jive, 6 years ago

Thanks:

So to avoid SAC being a bottleneck on edit access - let's promote the following people to administrator so they can provide access for their respective communities.

1) board members

  • board members can provide access for external relationships (partners and service providers)
  • board members can provide access for internal relationships (initiative participants)

2) officers

  • committee chairs can provide access for committee members
  • project officers can provide access to their project steering committee

comment:6 by jive, 6 years ago

I have updated Astrid's credentials so she can help manage board member access.

comment:7 by cvvergara, 6 years ago

Adding roles:

  • "Incubator" that allows:
    • Create, edit, publish and delete a project page
  • "Project PSC" that allows:
    • Create and edit a project page

So, for example: A new project enters incubation then the "Project PSC" members of the project get the role so that they can build up their project page Once its ready the "Incubator" gives the approval by publishing it. (comunication with Incubation maillist to ask for the approval would be needed)

what this does not cover: "Project PSC" can edit projects that don't belong to them. But the changes don't get published until Incubator publishes them. (comunication with Incubation maillist to ask for the approval would be needed)

What is expected: Maybe at the beginning projects want to refine they project page, but once its ready changes would be seldom.

Who gets "Incubator" role: Incubation committee Who gets "Project PSC" role: projects PSC members

Jody and me experimented on the Incubator role I experimented on the Project PSC role

So only "Incubator" and "Project PSC" can create a valid project page.

Just tested that some other roles can publish projects :(

comment:8 by jive, 6 years ago

cvvergara and myself implemented the above, opting to go for "Projects Author" and "Projects Editor" (rather than specifically tie roles to incubation committee, or marketing committee, or board or ....

The results are written up here: website roles

Next we need a plan to tell people about these roles, and give "editor" roles to the appropriate members.

comment:9 by jive, 6 years ago

While you can restrict website access by role, you can not restrict editing by role.

I was hoping to make it so GeoForAll Editors could edit the GeoForAll pages. As it is we will need to let GeoForAll Editors edit all pages.

comment:10 by jive, 6 years ago

So how is this working out? Been able to field several requests for access and supply appropriate roles.

Can we write up this result on the wiki and close this issue?

Last edited 6 years ago by jive (previous) (diff)

comment:11 by jive, 6 years ago

Resolution: fixed
Status: newclosed

Roles are documented here: https://wiki.osgeo.org/wiki/Website

Note: See TracTickets for help on using tickets.