Forum OpenACS Development: Re: XoWiki

Collapse
67: Re: XoWiki (response to 1)
Posted by Nima Mazloumi on
Using policy3 results to the below error.

I use xotcl-core 0.56.3 und xowiki 0.60.3.

can't read "policy": no such variable
while executing
"$policy enforce_permissions $object $method"
(procedure "call" line 5)
::6616827 ::xowiki::Package->call
invoked from within
"my call $page $method"
(procedure "invoke" line 12)
::6616827 ::xowiki::Package->invoke
invoked from within
"::$package_id invoke -method $m"
invoked from within
"::$package_id reply_to_user [::$package_id invoke -method $m]"
(file "/www/unima2/packages/xowiki/www/index.vuh" line 21)
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 {

Collapse
68: Re: XoWiki (response to 67)
Posted by Gustaf Neumann on
whatever the error is, it is not related with policy3. It might be a consequence of an earlier error, or maybe of a package reload. If you find a way to reproduce the error, please report.
Collapse
69: Re: XoWiki (response to 68)
Posted by Nima Mazloumi on
I was not able to reproduce the policy3 error but the unknown variable 'myvar' still exists even with a new Form and FormPages.

You can reproduce it this way. Create a new form:

template:leave empty
form:

<form>
<div class="form-item-wrapper">
<div class="form-label">Alternativen 
</div>
<div class="form-widget">Alt 1
<input type="checkbox" value="t" name="a1" /> Alt 2
<input type="checkbox" value="t" name="a2" />
</div>
</div>
</form>

constraints:
@cr_fields:hidden a1:boolean a2:boolean

Now create a new formpage but only check one of the two boxes. If you view the page everything is still fine.

now go back to form and add this to the form template:
@a1@ @a2@

Go back to the formpage. now you should get the message:
**** unknown variable 'a2' **** (::6546417 ::xowiki::FormPage->get_value)

Another problem I found while testing: Go back to form and add this constraint:

@table:a1,a2

When you go to the list view you will see one saying "yes" and one empty. Now edit the formpage and deselect the one selected and go back to the list view. it is still saying yes. go back and select the second save and deselect it and go to list view. now both say "yes".

A third thing I found: If I change to policy3 the list view is not permitted even though I am swa and have admin rights on the xowiki instance.

Collapse
70: Re: XoWiki (response to 69)
Posted by Gustaf Neumann on
Hi Nima,

the test cases appear to be correct in the head version. In the case of the table view, with "@table:a1,a2", it says first "yes" "no" and then "no" "no". I am not sure if it is worth backporting the fixes from the head version to oacs-5-3, since it is in some respects already quite different, and i have a very tough schedule until i leave on monday morning (including the materials for the conference).

The plan is to produce another stable version from head in the oacs-5-4 branch, which will have these problems fixed.

The permission stuff is simple to fix, there were no rules for Form in policy2 and policy3; see:
http://cvs.openacs.org/cvs/openacs-4/packages/xowiki/tcl/package-procs.tcl?r1=1.94&r2=1.95
One is only allowed to call methods if a policy permits it. Removing entries from there (or not adding it) makes methods unaccessible via the url interface.

Collapse
71: Re: XoWiki (response to 70)
Posted by Nima Mazloumi on
Thank you. I will test with head version.
Collapse
72: Re: Res: Re: XoWiki (response to 68)
Posted by Raúl Morales Hidalgo on
We get a similar error in an OpenACS 5.3 (oracle) checked out from CVS

can't read "policy": no such variable
while executing
"$policy defined_methods Package"
(procedure "resolve_page" line 9)
::950 ::xowiki::Package->resolve_page
invoked from within
"my resolve_page [my set object] method"
(procedure "invoke" line 6)
::950 ::xowiki::Package->invoke
invoked from within
"::$package_id invoke -method $m"
invoked from within
"::$package_id reply_to_user [::$package_id invoke -method $m]"
(file "/web/devext/packages/xowiki/www/index.vuh" line 21)
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..."

the versions are the ones from CVS oacs-5-3:

xotcl-core 0.56.3
xowiki 0.60.3

we have the error in aproximately half of the clicks within xowiki pages so we can't reproduce it always but very often.
It's not always in resolve_page, in fact more often we got it in the call procedure,

Any Ideas or any further things we should test?

thanks in advance