Skip to content

Commit

Permalink
Merge pull request #208 from okfn/orgs-doc-fix
Browse files Browse the repository at this point in the history 
Orgs doc fix
  • Loading branch information
@kindly
kindly committed Dec 14, 2012
2 parents fc5ec25 + 331d058 commit fe54ab0
Showing 1 changed file with 27 additions and 124 deletions.
151 changes: 27 additions & 124 deletions doc/organizations_and_groups.rst
View file
Expand Up @@ -80,7 +80,7 @@ User Stories that apply to both Organizations and Groups

* **Anyone** can see a list of all the site's organizations.
* **Anyone** can see a list of all the site's groups.
* **Anyone** can see a list of all an organization's _public_ datasets
* **Anyone** can see a list of all an organization's _public_ datasets
* **Anyone** can see a list of all a group's datasets (groups can't have
private datasets, they're all public)
* **Sysadmins** can create new organizations, and automatically become admins
Expand Down Expand Up @@ -141,7 +141,7 @@ organization is specified. Users who are not a member of an organization will
be able to add datasets to this default organization.

* **Sysadmins** can move datasets from one organization to another.

* **Sysadmins** can delete organizations, and this deletes all of the
organization's datasets.

Expand Down Expand Up @@ -188,150 +188,53 @@ Technical FAQ


The data model will not change from how it is currently::

+------------+
| |
+---+ dataset |
+------------+ +-----------+ | | |
| | | +---+ +------------+
| group +-----+ member |
| group +-----+ member |
| | | +---+ +------------+
+------------+ +-----------+ | | |
+---+ user |
| |
+------------+

The group table has a "type" field specifying if the table is an "organization"
or a "group".
The group table has a "type" field specifying if the table is an "organization"
or a "group".

Using the one 'group' table for both organizations and groups means you can't
have an organization and a group with the same name. This is probably a good
thing as it would be confusing for users anyway.

The member table has field called capacity which should be used as follows:

* When a dataset is a member of an Organization it must have capacity of
either public/private.
* When a dataset is a member of a Group it must have capacity of 'member'.
* When a user is a member of a Group/Organization it must have capacity
of admin/editor.


Transition
==========


I'd remove the member table as horrible and move to this model
::


+------------+
| |
+---+ dataset |
+-----------+ | | |
| group +---+ +------------+
| ownership |
| +---+ +------------+
+-----------+ | | |
+---+ group |
| |
+------------+



+------------+
| |
+---+ user |
+-----------+ | | |
| group +---+ +------------+
| membership|
| +---+ +------------+
+-----------+ | | |
+---+ group |
| |
+------------+

+----------------+
|group_membership|
+----------------+
|Group/Org |
|User |
|Role |
+----------------+

+----------------+
|group_ownership |
+----------------+
|Group/Org |
|Dataset |
+----------------+

Orgs would just be a group type with it's own forms and a field that
destiguishes it as an org. Probably it's own schema etc

An organisation would only be different from a group by this type unless I
am given explict differences (note: I have no real knowledge of groups only
that in the code)

If possible all actions will just be group_.... not organization_....

Any changes to the group model would be as minimal as possible


Admin
`````

Need to add some stuff to allow admin of group datasets etc both for
admin/sysadmins


Searches
````````

Search Indexes would be updated to contain privacy information for groups

Searches would be updated to not return private data. This may need some
thought to keep things running fast - public users would almost definatly be
a special case as this is a common usage


Need methods for group/org applications and admin

Do we need to move/migrate existing data?

Group/Org searches should seem different to the user so searching groups
only shows groups etc

I may need some help with the search stuff

Auth
````

All auth functions would be group_... but these would then internally use
the org_... functionality if the group is an org

Try to remove any old auth stuff if possible
The member table has field called capacity which should be used as follows:

Permissions to just be hard coded (as user stories) in this first phase but
keep an eye on future upgrades
* When a dataset is a member of an Organization it must have capacity of
'ozganization'.
* When a dataset is a member of a Group it must have capacity of 'member'.
* When a user is a member of a Group/Organization it must have capacity
of the users role eg. admin, editor, memeber

Sysadmins will have magic powers to see do anything

The package table has gained two new fields

Tests
`````
owner_org - the id of the owning organization
private - determines if the dataset is public or private
`
Config options
==============

Attempt to keep existing tests running and look at some tests for new
functionality.
The following config options have been created.

Misc
````
ckan.auth.user_create_organizations
ckan.auth.user_create_groups

There will be some integration issues but they are outside the scope of this
doc and the development cycle
ckan.auth.create_user_via_api
ckan.auth.create_dataset_if_not_in_organization

API
```
ckan.auth.anon_create_dataset
ckan.auth.user_delete_groups

Only actions will be supported for orgs - any v1/2 apis will only work for
groups orgs will 500
ckan.auth.user_delete_organizations
ckan.auth.create_unowned_dataset

0 comments on commit fe54ab0

Please sign in to comment.