Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Organization hierarchy #1038

Closed
davidread opened this issue Jun 24, 2013 · 7 comments
Closed

Organization hierarchy #1038

davidread opened this issue Jun 24, 2013 · 7 comments
Assignees

Comments

@davidread
Copy link
Contributor

Allow organizations to be assembled into a tree hierarchy. Use Member objects to link them, with a 'parent' or 'child' capacity.

Have config options to determine whether a user's admin/editor/member rights automatically apply to organizations lower in the hierarchy.

Add 'parent organization' field to the organization form. Show/hide it according to a config option 'organization_hierarchy.enabled'.

(We decided that an admin for an organization should decide who the org's parent should be, since that can only add extra rights to other users. The alternatives is that an admin for an organization can add child organizations, but that would give that admin new rights to the child. You could require that a user has to be admin for both the parent and the child to edit the hierarchy, but that is a much more complicated system to implement, manage, explain etc.)

Consider adding model functions to navigate up and down the tree, as DGU use.

No template additions required. Kindly says displaying the hierarchy could lead in lots of directions, so leave this to be done in extensions.

Needs tests.

A bit of documentation would also be helpful here.

@ghost ghost assigned davidread Jun 24, 2013
@tobes
Copy link
Contributor

tobes commented Jun 25, 2013

This would also imply groups too

@davidread
Copy link
Contributor Author

I'm not aware of any use cases for group hierarchies, so had only planned to do it for organizations. The auth is separate and can avoid the option in the form for groups. We might come up against an issue, but our preference is for avoiding worrying about considering the group permissions.

@tobes
Copy link
Contributor

tobes commented Jun 25, 2013

organizations are just groups. I'm not saying it needs to be active just reminding that that they co-exist and therefore adding it for one should allow it in the other even if not actually enabled anywhere.

@davidread
Copy link
Contributor Author

Not sure what you mean. The intention is that all of the changes will only apply to 'groups which are organizations' and none will change 'groups which are not organizations'.

davidread pushed a commit to datagovuk/ckan that referenced this issue Jul 22, 2013
davidread pushed a commit to datagovuk/ckan that referenced this issue Jul 22, 2013
davidread pushed a commit to datagovuk/ckan that referenced this issue Jul 22, 2013
davidread pushed a commit to datagovuk/ckan that referenced this issue Jul 30, 2013
davidread pushed a commit to datagovuk/ckan that referenced this issue Jul 30, 2013
…ed the sort ordering for some of the group functions.
davidread pushed a commit to datagovuk/ckan that referenced this issue Jul 30, 2013
davidread pushed a commit to datagovuk/ckan that referenced this issue Jul 30, 2013
davidread pushed a commit to datagovuk/ckan that referenced this issue Jul 30, 2013
@davidread
Copy link
Contributor Author

Have done:

  • model functions for navigating hierarchy (groups or orgs)
  • permissions cascading
  • created ckanext-hierarchy that displays organization tree
    With CKAN tests

Yet to do:

I may also look at #1032 and #1145 too.

davidread pushed a commit to datagovuk/ckan that referenced this issue Sep 6, 2013
* Fix - CONFIG_PERMISSIONS were not read properly following my prev changes
* Fix deleted child groups being visible.
* Fix up a couple of tests
davidread pushed a commit to datagovuk/ckan that referenced this issue Sep 12, 2013
davidread pushed a commit to datagovuk/ckan that referenced this issue Sep 12, 2013
Now member.table_id is the *parent* of member.group_id (not the child). This means the permissions work - a user needs permissions for the member.group_id to change its members, and it makes more sense for a group to choose its parents than its children. This is because a user with rights higher up the tree often gets given automatic rights to groups lower down. If he can also make any other group a child, then he would give himself rights over it.

Added test for the group permissions to check it made sense

Fixed bug in get_top_level_groups - the 'and' was ignored before. The existing test picked this up.

group.get_groups meaning is expanded. Seems to only get used in
_group_or_org_update and treats the result as parents. Needs further
examination when doing the form work on this ticket.
davidread pushed a commit to datagovuk/ckan that referenced this issue Sep 17, 2013
…['groups'] rather than custom 'parent'

Removed explicit creation of Members in the create/update logic functions - these were a hangover. Instead, the form just needs to ensure the parent group gets added to the group['groups'] and it will get set in the model_save as normal.

Group.get_group no longer used anywhere (and the caching looked ropey anyway) now that the previous bit is removed.

Added schema validator to ensure that no loops form in the hierarchy.

Downwards CTE needed ordering as found it also couldn't be relied upon to be in order it recursed, probably due to the join.

Removed duplicate 'groups' key in the group schema.
davidread pushed a commit to datagovuk/ckan that referenced this issue Sep 17, 2013
davidread pushed a commit to datagovuk/ckan that referenced this issue Sep 17, 2013
davidread pushed a commit to datagovuk/ckan that referenced this issue Sep 17, 2013
davidread pushed a commit to datagovuk/ckan that referenced this issue Sep 17, 2013
davidread pushed a commit to datagovuk/ckan that referenced this issue Sep 17, 2013
davidread pushed a commit to datagovuk/ckan that referenced this issue Sep 17, 2013
@davidread
Copy link
Contributor Author

This is complete now. In the end I made it work with both groups and organizations. The related extension for the front-end work is: https://github.com/datagovuk/ckanext-hierarchy and I created a pull request: #1247

davidread pushed a commit to datagovuk/ckan that referenced this issue Sep 23, 2013
davidread pushed a commit to datagovuk/ckan that referenced this issue Sep 23, 2013
davidread pushed a commit to datagovuk/ckan that referenced this issue Sep 24, 2013
davidread pushed a commit to datagovuk/ckan that referenced this issue Sep 24, 2013
… as SQLAlchemy objects.

Conflicts:
	ckan/tests/models/test_group.py
davidread pushed a commit to datagovuk/ckan that referenced this issue Sep 24, 2013
* get_parent_groups is used by DGU and no doubt others that use hierarchy.
* get_children_groups changed to return objects as that is more convenient
  for DGU.
davidread pushed a commit to datagovuk/ckan that referenced this issue Sep 24, 2013
* get_parent_groups is used by DGU and no doubt others that use hierarchy.
* get_children_groups changed to return objects as that is more convenient
  for DGU.

Conflicts:
	ckan/tests/models/test_group.py
davidread pushed a commit to datagovuk/ckan that referenced this issue Oct 3, 2013
davidread pushed a commit to datagovuk/ckan that referenced this issue Oct 3, 2013
kindly added a commit that referenced this issue Nov 7, 2013
davidread pushed a commit to datagovuk/ckan that referenced this issue Dec 9, 2013
davidread pushed a commit to datagovuk/ckan that referenced this issue Dec 9, 2013
davidread pushed a commit to datagovuk/ckan that referenced this issue Dec 9, 2013
@davidread
Copy link
Contributor Author

Closing, the pull request has been merged master in time for CKAN 2.2. #1247

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants