| Prev | Chapter�4.�Configuring a new OpenACS Site | Next |
|---|
The easiest way is to install the Edit-This-Page package.
Log in to the web site as an administrator.
Click on Admin > Install Software > Install from OpenACS Repository / Install new application
Choose Edit This Page and install
Follow the instructions within Edit This Page (the link will only work after Edit This Page is installed).
Go to /admin/permissions and grant Create to Registered Users
Suppose you install a new site and install Weblogger, and you want all visitors to see weblogger automatically.
On the front page, click the Admin button.
On the administration page, click Parameters link.
Change the parameter IndexRedirectUrl to be the URI of the desired application. For a default weblogger installation, this would be weblogger/. Note the trailing slash.
Every page within an OpenACS site is part of a subsite More information). The home page of the entire site is the front page is a special, default instance of a subsite, served from /var/lib/aolserver/$OPENACS_SERVICE_NAME/www. If an index page is not found there, the default index page for all subsites is used. To customize the code on the front page, copy the default index page from the Subsite package to the Main site and edit it:
cp /var/lib/aolserver/$OPENACS_SERVICE_NAME/packages/acs-subsite/www/index* /var/lib/aolserver/$OPENACS_SERVICE_NAME/www
Edit the new index.adp to change the text; you shouldn't need to edit index.tcl unless you are adding new functionality.
Almost all pages on an OpenACS site use ACS Templating, and so their appearance is driven by a layer of different files. Let's examine how this works:
+ +
The easiest way is to install the Edit-This-Page package.
Log in to the web site as an administrator.
Click on Admin > Install Software > Install from OpenACS Repository / Install new application
Choose Edit This Page and install
Follow the instructions within Edit This Page (the link will only work after Edit This Page is installed).
Go to /admin/permissions and grant Create to Registered Users
Suppose you install a new site and install Weblogger, and you want all visitors to see weblogger automatically.
On the front page, click the Admin button.
On the administration page, click Parameters link.
Change the parameter IndexRedirectUrl to be the URI of the desired application. For a default weblogger installation, this would be weblogger/
Every page within an OpenACS site is part of a subsite More information). The home page of the entire site is the front page is a special, default instance of a subsite, served from /var/lib/aolserver/$OPENACS_SERVICE_NAME/www. If an index page is not found there, the default index page for all subsites is used. To customize the code on the front page, copy the default index page from the Subsite package to the Main site and edit it:
cp /var/lib/aolserver/$OPENACS_SERVICE_NAME/packages/acs-subsite/www/index* /var/lib/aolserver/$OPENACS_SERVICE_NAME/wwwEdit the new index.adp to change the text; you shouldn't need to edit index.tcl unless you are adding new functionality.
Almost all pages on an OpenACS site use ACS Templating, and so their appearance is driven by a layer of different files. Let's examine how this works:
A templated page uses an ADP/TCL pair. The first line in the ADP file is usually: -
<master>
If it appears exactly like this, without any arguments, the template processer uses default-master for that subsite. For pages in /var/lib/aolserver/$OPENACS_SERVICE_NAME/www, this is /var/lib/aolserver/$OPENACS_SERVICE_NAME/www/default-master.adp and the associated .tcl file. -
The default-master is itself a normal ADP page. It draws the subsite navigation elements and invokes site-master (/var/lib/aolserver/$OPENACS_SERVICE_NAME/www/site-master.adp and .tcl)
The site-master draws site-wide navigation elements and invokes blank-master (/var/lib/aolserver/$OPENACS_SERVICE_NAME/www/blank-master.adp and .tcl).
Blank-master does HTML housekeeping and provides a framework for special sitewide navigation "meta" elements such as Translator widgets and Admin widgets.
Steps to Reproduce.�The events package does not allow users to register for new events.
Go to the http://yourserver.net/events as a visitor (ie, log out and, if necessary, clear cookies). This in on a 4.6.3 site with events version 0.1d3.
Select an available event
A link such as Registration: Deadline is 03/15/2004 10:00am. -� Login or sign up to register for this event. is visible. Click on "Login or sign up" -
Complete a new registration. Afterwards, you should be redirected back to the same page.
Actual Results: The page says "You do not have permission to register for this event."
Expected results: A link or form to sign up for the event is shown.
Finding the problem.�We start with the page that has the error. In the URL it's http://myserver.net/events/event-info.tcl, so open the file /var/lib/aolserver/$OPENACS_SERVICE_NAME/packages/events/www/event-info.tcl. It contains this line:
set can_register_p [events::security::can_register_for_event_p -event_id $event_id]
We need to know what that procedure does, so go to /api-doc, paste events::security::can_register_for_event_p into the ACS Tcl API Search box, and click Feeling Lucky. The next pages shows the proc, and we click "show source" to see more information. The body of the proc is simply
return [permission::permission_p -party_id $user_id -object_id $event_id -privilege write]
This means that a given user must have the write privilige on the event in order to register. Let's assume that the priviliges inherit, so that if a user has the write privilige on the whole package, they will have the write privilege on the event.
Setting Permissions.�A permission has three parts: the privilige, the object of the privilige, and the subject being granted the privilige. In this case the privilige is "write," the object is the Events package, and the subject is all Registered Users.
To grant permissions on a package, start at the site map. Find the event package and click "Set permissions".
Click "Grant Permission"
Grant the write permission to Registered Users.
OpenACS 5.0 offers a prettier version at /admin/applications.
<master>
If it appears exactly like this, without any arguments, the template processer uses default-master for that subsite. For pages in /var/lib/aolserver/$OPENACS_SERVICE_NAME/www, this is /var/lib/aolserver/$OPENACS_SERVICE_NAME/www/default-master.adp and the associated .tcl file.
+
The default-master is itself a normal ADP page. It draws the subsite navigation elements and invokes site-master (/var/lib/aolserver/$OPENACS_SERVICE_NAME/www/site-master.adp and .tcl)
The site-master draws site-wide navigation elements and invokes blank-master (/var/lib/aolserver/$OPENACS_SERVICE_NAME/www/blank-master.adp and .tcl).
Blank-master does HTML housekeeping and provides a framework for special sitewide navigation "meta" elements such as Translator widgets and Admin widgets.
Steps to Reproduce. The events package does not allow users to register for new events.
Go to the http://yourserver.net/events as a visitor (ie, log out and, if necessary, clear cookies). This in on a 4.6.3 site with events version 0.1d3.
Select an available event
A link such as Registration: Deadline is 03/15/2004 10:00am.
+» Login or sign up to register for this event. is visible. Click on "Login or sign up"
+
Complete a new registration. Afterwards, you should be redirected back to the same page.
Actual Results: The page says "You do not have permission to register for this event."
Expected results: A link or form to sign up for the event is shown.
Finding the problem. We start with the page that has the error. In the URL it's http://myserver.net/events/event-info.tcl, so open the file /var/lib/aolserver/$OPENACS_SERVICE_NAME/packages/events/www/event-info.tcl. It contains this line:
set can_register_p [events::security::can_register_for_event_p -event_id $event_id]
We need to know what that procedure does, so go to /api-doc, paste events::security::can_register_for_event_p into the ACS Tcl API Search box, and click Feeling Lucky. The next pages shows the proc, and we click "show source" to see more information. The body of the proc is simply
return [permission::permission_p -party_id $user_id -object_id $event_id -privilege write]
This means that a given user must have the write privilige on the event in order to register. Let's assume that the priviliges inherit, so that if a user has the write privilige on the whole package, they will have the write privilege on the event.
Setting Permissions. A permission has three parts: the privilige, the object of the privilige, and the subject being granted the privilige. In this case the privilige is "write," the object is the Events package, and the subject is all Registered Users.
To grant permissions on a package, start at the site map. Find the event package and click "Set permissions".
Click "Grant Permission"
Grant the write permission to Registered Users.
OpenACS 5.0 offers a prettier version at /admin/applications.
