Forum OpenACS Development: Re: XoWiki 0.31 problem with deleted pages

Collapse
Posted by Gustaf Neumann on
permission checked forced the user to login for all checks based on object ids. I have changed this in a way that it first checks whether the privilege was granted to the public, and if not, it requires a login. This is more costly, but the right thing.

please check out from CVS head.

Collapse
Posted by Prem Thomas on
Thanks, Gustaf. Checked out xowiki from head and tried it, but got the following error which I think is originating from xowiki-callback-procs.tcl, line 66

invalid command name "::xowiki::Object"
    while executing
"::xowiki::Object fetch_object -object ::$folder_id -item_id $item_id"
    (procedure "require_folder_object" line 24)
    ::833 ::xowiki::Package->require_folder_object
    invoked from within
"my require_folder_object"
    (procedure "init" line 5)
    ::833 ::xowiki::Package->init
    ::xowiki::Package ::xotcl::Class->create
    invoked from within
"my create ::$package_id -url $url"
    (procedure "require" line 8)
    ::xowiki::Package ::xo::PackageMgr->require
    invoked from within
"my require -url $url $package_id"
    (procedure "initialize" line 21)
    ::xowiki::Package ::xo::PackageMgr->initialize
    invoked from within
"::xowiki::Package initialize -ad_doc {

  This is the resolver for this package. It turns a request into
  an object and executes the object with the ..."
    (file "/usr/local/share/topaz/packages/xowiki/www/index.vuh" line 2)
    invoked from within
"source [ad_conn file]"
    (procedure "rp_handle_tcl_request" line 3)
    invoked from within
"$handler"
    ("uplevel" body line 2)
    invoked from within
"uplevel $code"
    invoked from within
"ad_try {
                $handler
            } ad_script_abort val {
                # do nothing
            }"
    invoked from within
"rp_serve_concrete_file [ad_conn file]"
    (procedure "rp_serve_abstract_file" line 60)
    invoked from within
"rp_serve_abstract_file "$root/$path""
    ("uplevel" body line 2)
    invoked from within
"uplevel $code"
    invoked from within
"ad_try {
            rp_serve_abstract_file "$root/$path"
            set tcl_url2file([ad_conn url]) [ad_conn file]
            set tcl_url2path_info..."

Collapse
Posted by Gustaf Neumann on
Since I got no fast feedback from thomas and i am leaving tomorrow for a short vacation, a short diagnosis, that might help some other people as well:

If one sees errors like this, please check the following items

  • Make sure, that acs-bootstrap-installer/bootstrap.tcl is up to date (it should include loading of the xotcl-core *init-files.
  • on cvs updates, it seems to happen that not all files are updated correctly. In the case of Thomas, it looks like the file xotcl-core/tcl/05-db-procs.tcl was missing.
The new versions of xowiki (in CVS head) need in most cases the new versions of xotcl-core from cvs head as well (it has the dependencies set). The dependencies are only checked on upgrades. If one simply updates the files, and reloads it, the dependencies are not checked...
Collapse
Posted by Prem Thomas on

As Gustaf notes above, the fix for my problem involved cvs updates of two packages, xotcl-core and acs-bootstrap-installer, on which xowiki depends. With this done, the error above disappeared.

Security policy3 for xowiki now works perfectly with permission setting on individual pages; pages with public read permission now do not ask for login prior to read.