Forum .LRN Q&A: Can't view forums in brand new installation

I have downloaded the latest OpenACS 4.6 and dotLRN 1.0 using -r oacs-4-6 and -r dotlrn-1-0 tags in CVS.

I have created a Community and a forum for it and when trying to "view" it, I get this error from the DB:

[12/Feb/2003:18:51:45][30324.10251][-conn7-] Notice: SQL():

        select site_node.url(node_id)
          from site_nodes
         where object_id = :package_id


[12/Feb/2003:18:51:45][30324.10251][-conn7-] Notice: bind variable 'package_id' = '0'
[12/Feb/2003:18:51:45][30324.10251][-conn7-] Error: ora8.c:3959:ora_tcl_command: Database operation "ns_ora" failed
[12/Feb/2003:18:51:45][30324.10251][-conn7-] Notice: RP (275.774 ms): error in rp_handler: serving GET /dotlrn/classes/new-media/internet/internet/forums/forum-view?forum_id=6267
        ad_url "/dotlrn/classes/new-media/internet/internet/forums/forum-view" maps to file "/web/webfolks/packages/forums/www/forum-view.adp"
errmsg is Query returned more than one row.
[12/Feb/2003:18:51:45][30324.10251][-conn7-] Notice: SQL():
            select 1
            from dual
            where 't' = acs_permission.permission_p(:object_id, :party_id, :privilege)

[12/Feb/2003:18:51:45][30324.10251][-conn7-] Notice: bind variable 'object_id' = '6175'
[12/Feb/2003:18:51:45][30324.10251][-conn7-] Notice: bind variable 'party_id' = '2110'
[12/Feb/2003:18:51:45][30324.10251][-conn7-] Notice: bind variable 'privilege' = 'admin'
[12/Feb/2003:18:51:45][30324.10251][-conn7-] Error: GET http://webfolks.nli.gl3/dotlrn/classes/new-media/internet/internet/forums/forum-view?forum_id=6267
referred by "https://webfolks.nli.gl3/dotlrn/classes/new-media/internet/internet/forums/"
Query returned more than one row.
    while executing
"ns_ora 0or1row nsdb0 {

        select site_node.url(node_id)
          from site_nodes
         where object_id = :package_id

      }"
    ("uplevel" body line 1)
    invoked from within
"uplevel $ulevel [list ns_ora $type $db $sql] $args"
    invoked from within
"db_exec 0or1row $db $full_name $sql"
    invoked from within
"set selection [db_exec 0or1row $db $full_name $sql]"
    ("uplevel" body line 2)
    invoked from within

This happens when this code is executed:

set notification_chunk [notification::display::request_widget \
    -type forums_forum_notif \
    -object_id $forum_id \
    -pretty_name $forum(name) \
    -url [ad_conn url]?forum_id=$forum_id \
]

Any hints on what the problem is?

Thank you in advance.

Collapse
Posted by Jeff Davis on
Bruno, it sounds like notifications is not mounted although
I thought we fixed the bit that generates the url to not
fail if that were the case.  The second is that there should not be any rows with object_id 0 but that is a bug somewhere else and only shows up since notifications is not mounted.
Collapse
Posted by Don Baccus on
There's always been an object 0 actually - the security context root.  There can never be a *package* or any other normal object there, though.

However the security context root is now at -4 and object 0 is the new "unregistered visitor" party I created in order to help speed permissions (gets rid of the UNION clause to return 0 in permissions views)

This is only in the PG version at the moment, I'm about 1/2 way through the changes for Oracle but haven't committed any.

Anyway ... Bruno's problem is the notifications package not being mounted though, as you mention ...

Collapse
Posted by Bruno Mattarollo on

Hello,

Thanks for the replies!

I mounted "notifications" and "attachments". In the installation documents there is no mention of that ... I vaguely remember in the older versions that you had to mount those two packages, but I forgot ... Thanks for reminding me :)

A patch to that document should be quite easy :)

Click on new sub folder in the right of Main Site at the top of the table. Enter notifications in the text box and hit the button.

There will be a new entry in the URL column for notifications with "(none)" in the application column, to the right of this, click the new application link. Enter Notifications in the text box and select Notifications from the drop-down list and hit the button.

There will now be "notifications" in the application column right next to the notifications/ URL.

Repeat the same procedure to create attachments/ sub folder and mount the new application Attachments.

Collapse
Posted by Jim Lynch on
Don B.:

You're changing the object 0 that gives site-wide admin permission? Won't that break code?

OK, if you're going to do that, could you add functions which returns the object ID of the security context root, site-wide admin and guest visitor objects (i.e., one function for each of these three, and more as required for special objects created by loading the initial data model)?

From what I could tell (and this has worked fine in the past), granting to some user admin permission on object 0 gave them site-wide admin. Has there always existed a more standardized approach (such as the one outlined above)?

If not, good; let's create it now so it can be properly documented; if so, good; where is it properly documented?

-Jim

Collapse
Posted by Dave Bauer on
Jim

There are already functions to return this information: acs__magic_object_id, which queries this table:


# select * from acs_magic_objects;
         name          | object_id 
-----------------------+-----------
 security_context_root |         0
 the_public            |        -1
 registered_users      |        -2
 default_context       |        -3
Most code uses that function. Any place that does not will need to be fixed.
Collapse
Posted by Jim Lynch on
Dave,

Thanks... I figured that would be there, but I was somewhat surprised by its simplicity and extendability.

But, now my question becomes, should I grant to my new admin user, admin on the security_context_root object?

-Jim

Collapse
Posted by Don Baccus on
Sorry for the late answer, but "yes" would be it :)

There's a link on the user info page (the one that let's you "become" a user, etc) that lets you make a user a site wide admin.

If you haven't guessed already, I wrote an upgrade script that changes references to the old security_context_root to the new one.

And code that referenced "0" rather than the symbolic security_context_root was ... broken and should be fixed regardless.