sbenthall commented 12 years ago

Overview

Based on feedback from the community, it is necessary to be able to apply permissions to Groups of users.

This proposal includes use cases for advanced permissions and groups based on feedback from deployments in small and big organizations. The content could have been split in two different GNIPS but the use cases make the separation line blurry. In essence, without a refactor of the permissions, many of the use cases for Groups could not be achieved.

Proposed By

Jeffrey Johnson Ariel Núñez

Assigned to Release

2.x

State

Approved

Motivation

Several Group and Group Security pull requests have been made but integrating the two was not easy. The main problem was the way Django's built-in groups model worked and the indirect relationships between Users and Models. Since Django 1.5, it is possible to override the User model and that opens the way to a harmonization.

Proposal

Geoserver should respect the permissions by hitting directly the Geonode database without passing through http calls to GeoNode. This would also help the decoupling between GeoNode and Geoserver. The Geoserver plugin could use django as ORM through Jython or so. This is complete pending merging of the updated stored procedure: https://github.com/GeoNode/geoserver-geonode-ext/pull/22
Use Django-guardian if possible otherwise use Django's permission system
Use configurable user model instead of profile (refactoring current profile implementation): https://docs.djangoproject.com/en/dev/releases/1.5/#configurable-user-model (we are already using Django 1.5)
Test whether the permissions on Layers, Maps and Documents can be centralized on the ResourceBase model (if this does not created and db query overload).
Create the following permissions:
- can_edit_style
- can_edit_metadata
- can_edit_data
- can_edit_permissions
- can_download
- can_view
Create a flag in the Layer model called 'published', this will allow admins to hide layers that have still not been cleared to be published, due to lacking metadata or styling.
Here are some mockups for the layer list and detail pages with different levels of access:

Limited Access limted_access

Read only read_only_home read_only_layerpreview

Read and download read_and_download_home read_and_download_layerpreview

Full Editing full_editing_layerpreview

Edit Data edit_data

Use cases

Administrator(Group): This is the highest level of access and will have full control over whole system. There will be limited users in this group and will be responsible to maintain the system.

a. Admin(User) i. Create Group ii. Edit Group iii. Delete Group iv. Create User v. Edit User vi. Delete User vii. Change Permission

```
Departments: Second level of access will have full control over subset of data. Each department will have separate group to ensure confidentiality of data. Hence there will be multiple group one each for every department. There will be two type of users in every department.
```
a. Group_Admin: i. There will be multiple group admin accounts representing the head of the department or any other person in charge from the respective department (Many admins to one group). ii. This user can add and manage new account for their employees and assign limited privileges (subset of what he is assigned from top order) to them. iii. This group admin cannot view the detail of groups and users in other groups. b. Users: i. This is the limited access account created by their group admin. ii. By default he can only view data available in the group. I would like to assign limited rights to Department groups so that they can perform the user administration task at their end. But at the same time have limited rights to access the whole system users, groups and irrelevant data.
Public Viewing

WFP:

Actors:

GIS Team at HQ
GIS focal point in regions
GIS officers in country

Layers:

WFP facilities
- Public viewing
- HQ manages permissions. Multiple officers at the HQ have group admin permissions
- Users should not be able to edit styles Optional:
- Groups related to spatial extents
- Permissions to edit a subset of the layer based on a group they belong to.

Administrative boundaries released by government

Accessible by GIS focal point in regions and GIS officers by country
Permissions managed by GIS officers in country
Issues
For private layers: how to allow WMS access but automatically restrict WFS access when accessing outside of GeoNode through the service url
Impact on the javascript widgets that allow users to change styles
Testing

Alternatives
Adding a third party groups app with support for CRUD operations via UI
Feedback

(None yet)

jj0hns0n commented 12 years ago

This is present in the social-synth branch, and should get pulled to dev in time for 2.0. More work needed on the group permissions. @lukeman should be working on this at some point.

ingenieroariel commented 11 years ago

This seems to be finished, any bugs related to groups can have their own ticket.

jj0hns0n commented 11 years ago

Should not have been closed! The implementation sits in an incomplete branch that has not been merged.

ingenieroariel commented 11 years ago

Thanks @jj0hns0n, oversight on my part.

jj0hns0n commented 11 years ago

moving to 2.1

ingenieroariel commented 10 years ago

We discussed this during the 2014 summit and will update the description above.

simod commented 10 years ago

we should also take into consideration #518

simod commented 10 years ago

we should take into consideration also #519

riaanvddool commented 10 years ago

Would this also allow groups within groups? Example department with sub-departments. This may be relevant: https://github.com/lukaszb/django-guardian

simod commented 10 years ago

hi @riaanvddool currently the groups permissions are implemented in master, I'm not sure whether is possible to make sub groups there. We are working towards a new permission system which is based on django-guardian. The idea is to include these improvements into the next release.

jj0hns0n commented 9 years ago

@simod can we go ahead and close this now?

simod commented 9 years ago

yes

rajanski commented 9 years ago

Hi guys, i cant figure how to get the view permissions on my layers as fine as in http://geonode.readthedocs.org/en/latest/_images/permissions.png, can anyone provide guidance?

jj0hns0n commented 9 years ago

Which version are you using?

On Tue, Apr 28, 2015 at 5:46 PM, rajanski notifications@github.com wrote:

Hi guys, i cant figure how to get the view permissions on my layers as fine as in http://geonode.readthedocs.org/en/latest/_images/permissions.png, can anyone provide guidance?

— Reply to this email directly or view it on GitHub https://github.com/GeoNode/geonode/issues/255#issuecomment-97235028.

rajanski commented 9 years ago

2.0.1 , i,.e. the one from the 12.04 ubuntu ppa

aptitude show geonode Package: geonode
State: installed Automatically installed: no Version: 2.0.1+thefinal0

my installations only shows the permissions as so:

simod commented 9 years ago

@rajanski the new permissions system is implemented on 2.4 which is available as beta for ubuntu 14.04.

rajanski commented 9 years ago

ok thanks, could you post here as soon as 2.4 is released stable? BTW geonode is a real fine piece of work , many thanks to all contributors for that!

simod commented 9 years ago

Thanks, will be for sure announced on the mailing lists and the website. By the way, the 2,4 is totally usable and quite stable as well if you want to give a try.

vdeparday commented 9 years ago

By the way, I don't think we should close this one. The specs as described are not quite implemented yet. We are still missing:

actual restriction on download on the GeoServer
the level of permission that is called 'limited access' in the specs.

simod commented 9 years ago

Vivien if I understand correctly the limited access is about make people aware of non permitted data right?

Il mercoledì 29 aprile 2015, Vivien Deparday notifications@github.com ha scritto:

By the way, I don't think we should close this one. The specs as described are not quite implemented yet. We are still missing:

actual restriction on download on the GeoServer

the level of permission that is called 'limited access' in the specs.

— Reply to this email directly or view it on GitHub https://github.com/GeoNode/geonode/issues/255#issuecomment-97416467.

Simone

vdeparday commented 9 years ago

Yes, exactly. I think it would be great because some GeoNode looks really empty if you go to them because actually most layers are behind a password. In the end, it would also likely foster more request to use the data and more open data.

On Wed, Apr 29, 2015 at 9:33 AM, Simone Dalmasso notifications@github.com wrote:

Vivien if I understand correctly the limited access is about make people aware of non permitted data right?

Il mercoledì 29 aprile 2015, Vivien Deparday notifications@github.com ha scritto:

By the way, I don't think we should close this one. The specs as described are not quite implemented yet. We are still missing:

actual restriction on download on the GeoServer

the level of permission that is called 'limited access' in the specs.

— Reply to this email directly or view it on GitHub https://github.com/GeoNode/geonode/issues/255#issuecomment-97416467.

Simone

— Reply to this email directly or view it on GitHub https://github.com/GeoNode/geonode/issues/255#issuecomment-97427482.

simod commented 9 years ago

Right. I think that this could be achieved by adding a tab in the search engine for restricted data with a dedicated API. Do you think could make sense? As mixing them into the normal data would be very tricky and lead to slow performances.

Il mercoledì 29 aprile 2015, Vivien Deparday notifications@github.com ha scritto:

Yes, exactly. I think it would be great because some GeoNode looks really empty if you go to them because actually most layers are behind a password. In the end, it would also likely foster more request to use the data and more open data.

On Wed, Apr 29, 2015 at 9:33 AM, Simone Dalmasso <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

Vivien if I understand correctly the limited access is about make people aware of non permitted data right?

Il mercoledì 29 aprile 2015, Vivien Deparday <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> ha scritto:

By the way, I don't think we should close this one. The specs as described are not quite implemented yet. We are still missing:

actual restriction on download on the GeoServer

the level of permission that is called 'limited access' in the specs.

— Reply to this email directly or view it on GitHub https://github.com/GeoNode/geonode/issues/255#issuecomment-97416467.

Simone

— Reply to this email directly or view it on GitHub https://github.com/GeoNode/geonode/issues/255#issuecomment-97427482.

— Reply to this email directly or view it on GitHub https://github.com/GeoNode/geonode/issues/255#issuecomment-97438391.

Simone

jj0hns0n commented 8 years ago

@simod lets discuss during the sprint in light of djmp. Moving to 2.7 anyway.

GeoNode / geonode

GNIP - Groups and advanced permissions #255

Overview

Proposed By

Assigned to Release

State

Motivation

Proposal

Use cases

Issues

Testing

Alternatives

Feedback