Forum OpenACS Q&A: Administering permission problem with Events Package instance on OACS 4.6.3

I have an instance of the events package loaded under /home. It inherits the permissions from /home. I have created venues, and an activity with three events.

If a non-registered user (not logged-in) navigates to an event, they are promted to "Log-in or Sign-up".

If a registered user navigates to an event, they get:
"You do not have permission to register for this event."

But it does work for an Admin user.

How do I set the permissions for the events to allow members of "Register Users" to register for an event?

Here is the permissions listing for the event:

Permissions for ACS Event 3356
Inherited Permissions

    * Registered Users, general_comments_create
    * The Public, read
    [direct site admins]

Posted by Ricardo Mireles on
This list on the structure of the OACS permissioning system
was provided by <jadeforrest> via the IRC #openacs (thanks):, html

There is also this forum post by Randy O'Meara on Aug 17 2003 which looks like the latest/most succinct on the subject:

<jadeforrest> also pointed out Joel Aufrecht's "How Do I" section found in Chapter 4 of the Administrator's Guide (Part II of the OpenACS Core Documentation):

Reviewing the docs listed above forced me to re-state my question.

I'm looking for how to USE the OACS permissioning system, not how to code witihin it or for it, nor designing an expansion to the default roles/relational segments/assignment rules, etc.

A quick read of the documentation above found plenty for the OACS developer, but only the one entry in the "How Do I" section for a site administrator, the person responsible for managing users and permissions.

In fact, in the preface to the "How Do I", Joel Aufrecht makes a distinction that highlights what I'm looking for when he differentiates between "configuring" and "customizing":

In this chapter, Configuring refers to making changes to a new OpenACS site through the web interface. In crude terms, these changes happen in the database, and are upgrade-safe. Customizing refers to changes that touch the file system, and require some planning if easy upgradability is to be maintained.

My need at this time is for information on "configuring" not "customizing."

Commenting on the need for documentation, <jadeforrest> added in the IRC #openacs:

Those type of docs are very needed! The documentation is getting really good, but that's the area it's most lacking. Admin-level docs.
Adding that "Some of that [admin-level information] is package specific." thus could be found in the package documentation.

But for my immediate specific need, the documentation for the Events Package does not state which OACS permission type should be assigned to an event so that members of group "Registered users" can actually use the tool as it was meant - to register for an event.

This is just one more post of the "need documentation" variety.