Forum OpenACS Development: XoWiki 0.30

• oo interface to objects:
  
  in order to perform operations on objects, XoWiki uses now in the oo style
  methods of these objects (in contrary to use global functions designed to work on
  all kind of objects). For example, in order to edit a page called en:test, one can
  call now a method edit of test instead of calling the global www/edit.tcl.
  global calls (such as getting the rss content of an XoWiki instance) are
  methods of the package object (see below)

• symbolic interface to objects
  
  XoWiki uses now on each possible place object names instead of object ids
  as external interface. Per default media wiki style names (underscore instead of spaces)
  are used (subst_blank_in_name is now per default 1).
  This is closely related to the point above.

• more beautiful links:
  
  Pages can be references now without the /pages/ prefix. instead of

  xowiki/pages/en/my_page

  one can use now

  xowiki/en/my_page

  The only current hard limitation is that pages are not allowed to start with "admin/"

• configuration management
  
  XoWiki supports now a 2-level configuration. In addition to the
  configuration over the folder object (see documentation), package
  parameters can be used. The configuration over the folder object
  have the advantage to allow computed values, etc. the package parameters
  are more user-friendly for non-programmers. The entries in the folder object
  take precedence over the values from the package parameters. The following
  package parameters are currently supported
  
  index_page
  weblog_page
  subst_blank_in_name
  use_gc (use general comments)
  use_tags (use tags, e.g. allow the user to tag pages)
  use_user_tracking (track usage of users such as last visited pages etc.)
  
  the last three package parameters allow to turn off various xowiki
  features.

• inclusion of XoWiki pages in other applications:
  
  In addition to the approach described in
  http://www.openacs.org/forums/message-view?message%5fid=459480
  one can use now symbolic names for the includes as well without any
  need to determine a package_id or item_id on the including side

     <master>
     <property name="title">@page_title;noquote@</property>
     <property name="context">@context;noquote@</property>
      bla bla bla...
     <include src="/packages/xowiki/lib/view" url="/xowiki/en/my_page">

• new class ::xowiki::Package to handle all package-specific calls
  and to capture the package specific information

• policy management
  
  XoWiki allows to define per instance different policies concerning
  rights on operations callable over the web. Only methods that are covered by an policy are callable over the web.
  A policy can contain context dependent permissions. The
  following definition is the default policy for XoWiki.
  
  It says for example, that the method reindex of the package
  requires admin rights on the package id, or that edit of
  ordinary pages requires write permissions, whereas an
  edit operation of an instance of ::xowiki::Object requires admin rights.
  
  The policy is used for guarding the calls as well as
  for deciding what links should be presented to the users.

     Policy policy1 -contains {
      Class Package -array set require_permission {
        reindex            {{id admin}}
        rss                none
        edit-new           {{{has_class ::xowiki::Object} id admin} {id create}}
      }
      Class Page -array set require_permission {
        view               {{package_id read}}
        revisions          {{package_id write}}
        edit               {{package_id write}}
        make-live-revision {{package_id write}}
        delete-revision    {{package_id admin}}
        delete             {{package_id admin}}
        save-tags          login
        popular-tags       login
      }
      Class Object -array set require_permission {
        edit               {{package_id admin}}
      }
    }

• numerous other changes
  * default page is now .../admin/list
  * improved admin pages (containing date, sortable, warnings)
  * update script to get rid of orphan entries created by content_item__new(),
  when title is provided

  The documentation should be updated during the next days.

-gustaf

If you do not use subst_blank_in_name and allow spaces in names and URLs there is a bug

around line 548 in xowiki-procs.tcl

if {$granted} {
if {[$object istype ::xowiki::Package]} {
set base [$package_id package_url]
if {[info exists url]} {
return [uplevel export_vars -base $base$url [list $args]]
} else {
lappend args [list $method 1]
return [uplevel export_vars -base $base [list $args]]
}
} elseif {[$object istype ::xowiki::Page]} {
set base [$package_id url]
lappend args [list m $method]
return [uplevel export_vars -base $base [list $args]]
}

I cahnges the $base variable referece to \"$base\" to quote the value of $base (also did $base$url)

There is still an issue when creating the edit form if you use the [ or ] characters in the name, it is trying to execute it as a tcl proc. I could not figure out where to apply the proper escaping in that.

We probably should disallow [ and ] in names/urls anyway, but someone might also use it in a title, and the same issue occurs.

Database operation "dml" failed (exception ERROR, "ERROR:  insert or update on table "xowiki_references" violates foreign key constraint "$1"
DETAIL:  Key (reference)=(331757) is not present in table "cr_items".
")
ERROR:  insert or update on table "xowiki_references" violates foreign key constraint "$1"
DETAIL:  Key (reference)=(331757) is not present in table "cr_items".

The ::Generic::CrItem lookup -name [my name] -parent_id [my folder_id]

call in link-procs.tcl is somehow returning an item_id that is no longer in cr_items.

I tried the call from the ds/shell and it returned 0 so I don't understand how this is happening. Any help is appreciated!

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.

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}}
     }
   }


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.

I am posting here to open discussion and make sure, if I find an issue, that the correct fix is applied. Luckily XoWiki has a very active package maintainer in Gustaf and we all appreciate it.

I've been trying to upgrade XoWiki and have had an afternoon of no luck.

I'm running OpenACS 5.2.3b2 with XoTcl 1.4.0 and Postgresql 7.4.x. Starting from a brand new install, I grabbed the XoTcl Core 0.41 apm and the Xowiki 0.32 apm, installed them and get the following error when I go to /xowiki for the first time.

I nuked every thing and tried previous versions of xotcl-core and xowiki and got an error that looked like a mal-formed SQL statement when trying to create the package.

Any thoughts?

Thanks,

Matt

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

ERROR: insert or update on table "acs_objects" violates foreign key constraint "acs_objects_package_id_fk"
DETAIL: Key (package_id)=(0) is not present in table "apm_packages".

SQL: select content_item__new('::741',741,null,null,null,'506',null,null, 'content_item','::xowiki::Object',null,NULL,NULL, NULL,null,null,null,'f','text', 0)
while executing
"ns_pg_bind 0or1row nsdb0 { select content_item__new(:name,741,null,null,null,:creation_user,null,null, 'content_item',:object_type,null,:description,:..."
("uplevel" body line 1)
invoked from within
"uplevel $ulevel [list ns_pg_bind $type $db $sql]"
("postgresql" arm line 2)
invoked from within
"switch $driverkey {
oracle {
return [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
"uplevel 1 $code_block "
invoked from within
"db_with_handle -dbn $dbn db {
set selection [db_exec 0or1row $db $full_name $sql]
}"
(procedure "db_string" line 8)
invoked from within
"db_string insert_item " select content_item__new(:name,$parent_id,null,null,null,:creation_user,null,null, 'content_item',:object_type,null,:descripti..."
invoked from within
"set item_id [db_string insert_item " select content_item__new(:name,$parent_id,null,null,null,:creation_user,null,null, 'content_item',:object_type,nu..."
("uplevel" body line 5)
invoked from within
"uplevel 1 $transaction_code "
(procedure "db_transaction" line 1)
invoked from within
"db_transaction {
$__class instvar storage_type object_type
$__class folder_type -folder_id $parent_id register
db_dml lock_objects "..."
(procedure "save_new" line 23)
invoked from within
"next"
(procedure "save_new" line 3)
::741 ::Generic::CrCache::Item->save_new
invoked from within
"::$folder_id save_new"
(procedure "require_folder_object" line 34)
::734 ::xowiki::Package->require_folder_object
invoked from within
"my require_folder_object"
(procedure "init" line 7)
::734 ::xowiki::Package->init
::xowiki::Package ::xotcl::Class->create
invoked from within
"::xowiki::Package create ::$package_id -folder_id $folder_id"
invoked from within
"set Package [::xowiki::Package create ::$package_id -folder_id $folder_id]"
(file "/usr/local/www/bitdojo.org-dev/packages/xowiki/www/index.vuh" line 15)
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..."

Thanks! -- as I embarassedly write on the blackboard 100 times "I will make sure to _thoroughly_ read threads before posting"

wrong # args: should be "ns_cache names cache"
while executing
"ns_cache names xowiki_cache link-*-$folder_id"
(procedure "update_references" line 17)
::xowiki::f1 ::xowiki::WikiForm->update_references
invoked from within
"my update_references"
(procedure "new_data" line 7)
::xowiki::f1 ::xowiki::WikiForm->new_data
invoked from within
"::xowiki::f1 new_data"
invoked from within
"set item_id [::xowiki::f1 new_data]"
("uplevel" body line 1)
invoked from within

Next thoughts? I've got the latest AOLserver FreeBSD package so I'm not convinced it's an obsolete nscache module, but I don't have any other ideas.

Matt

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

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.

All the best -g

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.