XoWiki 0.30 seems to break pretty badly on upgrade. If I visit the index page with an XoWiki Object defined in the xowiki package I get something like this:

invalid command name "292676"

    while executing

"$folder_id get_payload index_page"

    invoked from within

"if {![info exists object_type]} {

  set index_page [$folder_id get_payload index_page]

  if {$index_page ne ""} {

    set item_id [Generic::CrItem loo..."

    ("uplevel" body line 36)

    invoked from within

"uplevel {

ad_page_contract {

  This is the main page for the package.  It displays all entries

  provides links to create, edit and delete these

I just did someting and it seems to work,

I copied back the XOwiki 0.28 code, restarted aolserver, and it still didn't work. So I copied the 0.30 code back, and without restarting, now it works.

I restarted again, and i can view pages, but not edit them:

can't read "edit_form_page_title": no such variable

    while executing

"lang::util::localize ${edit_form_page_title}"

    invoked from within

"set __adp_properties(title) "[lang::util::localize ${edit_form_page_title}]""

    ("uplevel" body line 5)

    invoked from within

"uplevel {

set __adp_output ""

I definitely needed to revert xotcl-core.

It appears xotcl-core is not backwards compatible, the xowiki code from previous versions doesn't work with the latest xotcl-core (AFAICT)

Any ideas?

-gustaf

Great work.

Two issues we found testing:

1) If you have existing pages with spaces in the names and upgrade the links to those pages can't be resolved because the resolver converts the spaces to underscores. We fixed by renaming the pages since new pages automatically are converted to underscores.

2) In renderng the links a link like this [[A Page Name]] will resolve to A_Page_Name with link text of A_Page_Name. I commented out line 728 in xowiki-procs.tcl to keep the original link as the link text. This way the editor can type the nice name, and get directed to the correct page, without having to add a seperate label for the link.

We are interested in either applying 2 or adding an additional option, if you think that should not be the default behavior.

issue 2: doing so will ulgify typed links (such as glossary links). The right thing is to use another variable normalized_name for the result of the normalizing method and use stripped_name for the label and normalized_name in the arguments of the link object.

issue 3: right. the better fix is to use list around the base argument of export_vars (3 times). this allows as well square brackets.

I'll polish the current work with the File class in xowiki and commit this together in the next few days.

-gustaf

If you need the fix soon, i can commit the current snapshot, otherwise i need a little time for polishing [[image:dave.png]] and [[file:docu.pdf]]. In the current snapshort, binary files are sometimes altered during download...

I have an unrelated question about permission granularity. We have a need to be able to add specific permissions for individual pages through the UI.

There are many use cases that come to mind, but the one that is relevant to us right now has to do with wanting to hide certain pages from certain users for an internal study we are planning. A more general use case is wanting to protect a controversial page from general edit.

What are your plans in this direction? How should we implement this?

Thanks,
Carl

P.S. We are benefiting greatly from your work.

... here is a nice logo [[image:DotLrnLogo.gif|Logo of .LRN]] and the printed documentation [[file:documentation.pdf|The .LRN User Handbook]] ....

This is implemented via a new class ::xowiki::File, a subclass of ::xowiki::Page. Therefore it reuses most of its properties. Files and images "know", where they are included (which pages reference them) and provide back-links to the including pages, they can be used in categories, they can be tagged (like in de.icio.us), they are contained in the rss or the weblog, they are included in the search (e.g. pictures are indexed via their title and description)

In later versions of xotcl, it should be possible to export and import files like other pages as well to transfer content easier between servers.

I was fighting quite long with a very strange problem, which is apparently Mac OS X specific: While the download with most of my test files (binary or not) worked without any problems, one .pdf file appeared truncated after download. While the original file size is 948130, the file had a size 143360 after download, although the content length in the http headers was correct. i certainly expected the bug to be somewhere in the newly implemented code of xowiki.

It took me a while to figure out, that the same happens with file-store as well. Interesting enough, the file download works correctly with bgdelivery. The problem turned out to be a configure problem, which sets HAVE_POLL to 1, where POLL does not seem to work together with aolserver (4.0.10). Compiling aolserver 4.0.10 with -DHAVE_POLL=0 solves the problem. Where available, xowiki will deliver files with bgdelivery.

• Direct inclusion of xowiki pages (using e.g. {{en:my_page}}, somewhat similar to [[en:my_page]]): Direct inclusion is significantly faster than adp inclusion, which can still be achieved via {{adp portlets/wiki {name en:my_page}}}

• Easier provision for default xowiki pages (default index page, default weblog page). See xowiki/www/default-pages.

• Some cleanup: removal of obsolete files, fix when mounting XoWiki the first time.
Enjoy.

xowiki 0.33, available since sunday fixes the problem you are mentioning. it is not a malformed SQL, but a 0 valued package_id. The last line of my announcement of 0.33 references the problem you are observing with 0.32.

I grabbed the head (made sure it was 0.33). Dropped the database, installed from scratch again. Reread this whole thread (cross my fingers I'm not overlooking anything obvious) and installed XoWiki. I get the following:

Database operation "0or1row" failed (exception NSDB, "Query was not a statement returning rows.")

SQL: insert into xowiki_objecti (item_id,revision_id,creation_user,title,description,mime_type,nls_language,text,page_title,creator) values ('744','745','506','::743',NULL,NULL,NULL,'# this is the payload of the folder object

set index_page "en:index"
',NULL,NULL)
while executing
"ns_pg_bind 0or1row nsdb0 {insert into xowiki_objecti (item_id,revision_id,creation_user,title,description,mime_type,nls_language,text,page_title,creat..."
("uplevel" body line 1)
invoked from within
"uplevel $ulevel [list ns_pg_bind $type $db $sql]"
("postgresql" arm line 2)


I've snipped the error listing.

Matt

xotcl-core checks, whether oacs 5.3.0d2 or newer is installed and chooses the appropriate database-operation, unless it is stated differently, as on my notebook.

For 1 minute an 4 seconds, a incorrect version was in cvs:
http://cvs.openacs.org/cvs/openacs-4/packages/xotcl-core/tcl/generic-procs.tcl?r1=1.21&r2=1.22

maybe an update solves the problem....

Speaking of hardware, the new Mac Pros presented just now at WWDC sound like great machines for OpenACS (4 cores...)

It should be possible to write some code to add files/images via xinha to xowiki folders, but the dialogs must be changed due to the wiki style nameing conventions and different urls. This would be xowiki only.

dave is working on a image upload where images are stored as subobjects of arbitrary objects (as well xowiki pages), which have the property that they will be deleted when the parent object is deleted.

In /xowiki/tcl/package-procs.tcl, the ::xowiki::Package create instproc was commented out for some reason, so when a new ::xowiki::Package was getting created in /xowiki/www/index.vuh, it wasn't getting created cleanly/correctly.

Restoring that instproc seems to do the trick -- at least the image object gets created and the page will display once you navigate back to it. However, the image object creation step return an error from the ::xowiki::Link::image render proc:

 [08/Aug/2006:15:00:48][6355.1029776][-conn:oacs52::0] Error: POST http://127.0.0.1:8052/pages/?object%5ftype=%3a%3axowiki%3a%3aFile&edit%2dnew=1&return%5furl=%2fpages%2fen%2fTest
referred by "http://127.0.0.1:8052/pages/?last%5fpage%5fid=11519&object%5ftype=%3a%3axowiki%3a%3aFile&name=image%3atest10%2ejpg&edit%2dnew=1&title=test10%2ejpg&return%5furl=%2fpages%2fen%2fTest"
invalid command name "::xotcl"
    while executing
"$page lappend references [list $item_id [my type]]"
    (procedure "render" line 8)
    ::xotcl::__#35 ::xowiki::Link::image->render
    invoked from within
"$l render"
    (procedure "get_content" line 23)
    ::xotcl::__#32 ::xowiki::File->get_content
    invoked from within
"my get_content"
    (procedure "render" line 11)
    ::xotcl::__#32 ::xowiki::Page->render
    invoked from within
"$data render -update_references"
    (procedure "update_references" line 8)
    ::xowiki::f1 ::xowiki::WikiForm->update_references
    invoked from within
"my update_references"
    (procedure "new_data" line 7)
    invoked from within
"next"
    (procedure "new_data" line 4)
    ::xowiki::f1 ::xowiki::FileForm->new_data
    invoked from within
"::xowiki::f1 new_data"
    invoked from within
"set item_id [::xowiki::f1 new_data]"

This looks like it's probably due to a typo, but I can't figure it out.

The most important changes are:

• fixes for the mentioned bugs (and a few unmentioned more)

• notifications (configurable via package_parameter)

• some code rearrangements (e.g xowiki-callback-procs)

• improved div handling

• removed one more obsolete file (view.adp)

• using objects for default pages to allow for different
  types of pages and specifying page title etc.
  (default pages are created from files in the CR on
  demand and can be altered per instance; xowiki comes
  with a default index page (xowiki/index) and weblog
  page; created for example, when someone clicks on a tag)

as always, the newest xowiki version is in cvs HEAD

ns_cache names cachename ?pattern?

since a couple of ... years (?). Get a recent version of nscache

cvs -z3 -d:pserver:anonymous@aolserver.cvs.sourceforge.net:/cvsroot/aolserver co nscache

seems, as if xowiki exercises some oacs componens more than other packages....

-gustaf

yesterday I did a fresh install of xotcl-core 0.42 and xowiki 0.34 and today upgraded to 0.35. In other sites I'm yet using xowiki 0.24 and the improvements are really staggering!

However, I had problems loading and retrieving files and images to and from xowiki folders. I tried loading a file in two ways:

1. creating an ::xowiki::File and then referencing it with the new syntax [[file:myfile|My File]] from a ::xowiki::Page
2. creating an ::xowiki::Page and a link to a non existent file with the same syntax and then clicking on the '[' to upload the file

Even worst, if i put a reference to an image on a page, the page hangs and the link to the image don't shows itself.

All the rest seems to work well, and of course I can continue to use Xinha to load and reference file and images, but the new way is really more clean and simple.

i deduce from your mail, that the upload of the image went well (say [[image:DotLrnLogo.gif]], you seen the uploaded entry from the admin pages) but the view of the image (like /xowiki/image/DotLrnLogo.gif?m=download) hangs

yes, I see the object from the admin pages, but when I click to view it the page hangs.

What operating system is the server? In what browser does this happen?

Linux RedHat 8.0 - Firefox 1.5.0.6

Do you see an error message in the log file?

Yes, there is an error in the log file:
invalid command name "throttle" while executing "throttle get_context"
Sorry to not have hilighted this before. Aolserver starts fine without any errors.

installing xotcl-request-monitor fixed the problem.

i have just committed a small experimental enhancement to xowiki 0.36. The new ::xowiki::policy3 allows for checking of individual pages (policy 1 and 2 check only rights on the package). When policy 3 is activated the admin page shows an additional column for managing permissions of individual pages. The aggregating views don't evaluate the
permissions for the time being.

This approach is already fine for protecting individual pages (prohibiting edits, no problems with aggregations), but i am not sure whether this is the right approach to hide e.g. work in progress. Permission checking is quite expensive in openacs. Checking on the package level scales much better, since this is much better for caching, when many user and many pages are involved. Checking on instance level needs a space of packages * users * privileges. For checking on instance level, the needed space is much larger (objects * users * privileges). Furthermore, caching does not work well, since the probability that the same user e.g. reads the same object twice in a session is much smaller the that the same user reads two different objects form the same package in a session.

In learn@wu, we are using an "active" flag, which hides pages from non-admins. This flag can be efficiently checked in all sql queries with more or less no extra cost.

Btw, the policy manager allows as well to use for certain operations on certain pages mixed kinds of checking. Depending on the object type or a predicate satisfiable from the page instance one can use for certain operations package level or instance level checking.

Below is for reference policy3. It differs from policy2 essentially by using the attribute item_id instead of package_id for checking. It can be activated form the package parameter page (conveniently reachable from the admin pages).

best regards
-gustaf


   Policy policy3 -contains {
     #
     # we require side wide admin rights for deletions
     # we perform checking on item_ids for pages.
     #
  
     Class Package -array set require_permission {
       reindex {{id admin}}
       rss none
       delete swa
       edit-new {{{has_class ::xowiki::Object} id admin} {id create}}
     }
  
     Class Page -array set require_permission {
       view {{item_id read}}
       revisions {{item_id write}}
       edit {{item_id write}}
       make-live-revision {{item_id write}}
       delete-revision swa
       delete swa
       save-tags login
       popular-tags login
     }
  
     Class Object -array set require_permission {
       edit {{package_id admin}}
     }
     Class File -array set require_permission {
       download {{package_id read}}
     }
   }


invalid command name "292676"

while executing

"$folder_id get_payload index_page"

invoked from within

"if {![info exists object_type]} {

set index_page [$folder_id get_payload index_page]

if {$index_page ne ""} {

set item_id [Generic::CrItem loo..."

("uplevel" body line 36)

invoked from within

"uplevel {

ad_page_contract {

This is the main page for the package. It displays all entries

provides links to create, edit and delete these

Gustaf,

I'm using xowiki 0.38 and xotcl-core 0.45 and implemented security policy 3 to set write permissions for individual pages. This works fine, but I had a problem with read permissions. All the pages on this wiki instance allow public reading without login, the intended effect. When I switch from security policy 1 to either 2 or 3, the public can no longer read the pages; login is required. I double checked the permission using the lock icon in the Administration section of xowiki and read by the public is enabled; however, I still get the login page on attempted read.

I changed the view line in policy 3 in package-procs.tcl:

Class Page -array set require_permission {
view none
...

and this allowed public reading. However, this removes all ability to limit access to other pages. Is there another way to accomplish this?

Also, perhaps because of caching, changes to the tcl code in the file above, were not reflected in the site unless I restarted AOLserver.

Thank you for all the work you've put into this very useful package.

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..."

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.