Opened 7 years ago
Closed 7 years ago
#2075 closed task (fixed)
Handling roles
Reported by: | cvvergara | Owned by: | |
---|---|---|---|
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 , 7 years ago
comment:2 by , 7 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 , 7 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:5 by , 7 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 , 7 years ago
I have updated Astrid's credentials so she can help manage board member access.
comment:7 by , 7 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 , 7 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 , 7 years ago
comment:10 by , 7 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?
comment:11 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Roles are documented here: https://wiki.osgeo.org/wiki/Website
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.