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
Comments
This would also imply groups too |
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. |
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. |
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'. |
…ed the sort ordering for some of the group functions.
Have done:
Yet to do:
|
* Fix - CONFIG_PERMISSIONS were not read properly following my prev changes * Fix deleted child groups being visible. * Fix up a couple of tests
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.
…['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.
And tidy typos etc.
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 |
… as SQLAlchemy objects.
… as SQLAlchemy objects. Conflicts: ckan/tests/models/test_group.py
* 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.
* 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
Conflicts: ckan/model/group.py
…group in the new-package form.
Closing, the pull request has been merged master in time for CKAN 2.2. #1247 |
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.
The text was updated successfully, but these errors were encountered: