Forum OpenACS Development: creating default group sets for package instances

Collapse
1: creating default group sets for package instances
Posted by Torben Brosten on 10/06/07 12:32 PM
Hi,

Are there any packages that I can use as an example of how to create a set of group_types that correspond to the various combinations of permissions: read, create, write, delete, admin for a package, and where a set of these groups are created for each instance of the package?

Also, since I'm working on numerous packages simultaneously, are these the procs to use:

group_type::new

group::new

permission::grant (for granting permissions to these groups)?

Or are best practices different than this?

btw, this is regarding coding for compatibility in OpenACS 5.3 or higher.

Thanks in advance,

Torben

Collapse
2: Re: creating default group sets for package instances (response to 1)
Posted by Dave Bauer on 10/06/07 02:44 PM
I don't think you need group_types.

You probably way to create an application group (a group that has a package_id) then crate roles and relational segments within the group for that package.

Then you can grant whatever combination of privileges for each role.

I am not sure there is a simple example available. dotlrn uses this extensively but strangely uses group types for EVERY group (which maybe have been overkill) so I don't recommend as an example unless you want to have infinitely complex code to support infinitely complex applications.

Collapse
3: Re: creating default group sets for package instances (response to 1)
Posted by Torben Brosten on 10/06/07 09:53 PM
Are group_types useful for granting a user (or group of users) specific privileges to all instances of a package-key?

Here's a use case I need to consider:

There are N subsites, each subsite represents a company department, project/program or warehouse etc. The function of handling accounts payables (vendor invoices etc) are handled by the same people regardless, so they need access to a certain part of each subsite, but not the other parts.

Maybe the way to handle this is to give them their own subsite and access via some kind of grouping in parameters..

Collapse
4: Re: creating default group sets for package instances (response to 3)
Posted by Tom Jackson on 10/07/07 11:01 AM
Are you working with already written software? If not, you have lots of options to avoid sending your accounting people to a bunch of different subsites to do their work. Otherwise you might have to go page by page through the app and figure out what to do, then replicate this on each subsite. But don't add any privileges, they don't help much.
Collapse
5: Re: creating default group sets for package instances (response to 1)
Posted by Torben Brosten on 10/07/07 01:17 PM
The software isn't written yet. There's still time to modify the data model etc.

I was looking at the use case as each project/area having vertical orientation and the accounting as having horizontal orientation (or visa-versa), but that hasn't been very practical.

Now I am seeing the orientation as being more tree-like, where a primary subsite contains project/area subsites, and the primary subsite also has an instance that can access the other instances that are within the same subsite and subsites mounted within it.

Any suggestions?