Forum OpenACS Q&A: Guidance on groups ui

Hi all, I'm finally getting around to actually using my openacs installation for something other than a photo depository. I'm trying to understand how I go about putting members into groups that can then be given permission to access specific pages/areas of the site. The admin manual has lots of info on parties and groups and rel segs but it's all from a database point of view. The ui is not very instructive at this stage. Here's how I'm guessing it should be done based on looking over the ui: 1. add a sub-group type under the main groups level in the group types section of the advanced administration page 2. Click on the new group type to get to that group types admin page 3. click on 'add a group of this type' which in theory creates a group that members can be added to - unfortunately I get this error when trying to add a group of this type:

can't read "formerror(group.group_name)": no such variable
    while executing
"lang::util::localize $formerror(group.group_name)"
    ("uplevel" body line 1)
    ("eval" body line 1)
    (procedure "template::adp_eval" line 1)
    invoked from within
"template::adp_eval code"
    (procedure "template::form::generate" line 21)
    invoked from within
"template::form::generate add_group"
    ("eval" body line 1)
    invoked from within
"eval template::form::$command $args"
    (procedure "template::form" line 2)
    invoked from within
"template::form generate add_group "
    invoked from within
"append __adp_output "[template::form generate add_group ]""
    ("uplevel" body line 21)
    invoked from within
"uplevel {
    	  set __adp_output ""

    set __adp_master [template::util::url_to_file "[ad_parameter -package_id [ad_conn subsite_id] DefaultMaster ..."
    (procedure "template::code::adp::/var/lib/aolserver/bradworld/packages/a..." line 2)
    invoked from within
"template::code::${template_extension}::$__adp_stub"
    (procedure "template::adp_parse" line 68)
    invoked from within
"template::adp_parse [file root [ad_conn file]] {}"
    (procedure "adp_parse_ad_conn_file" line 5)
    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..."

First off, am I on the right track to add a group? Second - any thoughts on the error? I'm using the latest version upgraded from the repository

I fixed this bug on head a couple days ago. If this was 5.1.4
then I can tell you what to fix it (although I did not realize
it was broken anywhere besides head).

Make this one line change
http://cvs.openacs.org/cvs/openacs-4/packages/acs-templating/tcl/parse-procs.tcl?r1=1.26.2.5&r2=1.26.2.6

The problem is that the change Don made broke things as a side effect of another bug in another regular expression elsewhere.

Things are not so simple.

This is really a DaveB change so he should take a look. He had made the change in the noquote parse procs for @, but not the "normal" one. In other words he changed things so @x.y.z;noquote@ would be recognized by not @x.y.z@.

He made this change because there was code using vars of that form which had snuck in and weren't being recognized. I added the change to the second parse proc because there was also code that used vars of the @x.y.z@ form as well as @x.y.z;noquote@. Plus, as should be obvious I hope, both forms should except the same syntax for vars.

The one line rollback will ...

1. Break some existing code, though unfortunately I don't remember where (might be bug-tracker, template list builder, or forums since that's where I've been spending time recently).

2. Will cause the syntax for vars accepted by "noquote" to differ from the syntax accepted for un-noquoted vars, which is, of course, absolutely BOGUS.

I suggest Dave remind us as to exactly why he needed to allow @x.y.z@ style vars in the first place and maybe we can figure out a way to fix this that really works in all cases - or we can rewrite the code that caused Dave to make this change in the first place.

Making that one line change will make the code broken the way it was broken since it was written. The right fix is to put
the . back in and change the regexps in the if tag and
elsewhere to make them consistent. That is what I have done on HEAD.

The reason x.y.z needs to parse to x(y.z) is because if you
create array variables in forms you need the formerror key and some other things to be able to parse this
(when element.id is group.group_name)

<if \@mailto:formerrer.@element.id@\@ nil>

to

if {[exists_and_not_null formerror(group.group_name)]}

If the regexps are inconsistent the nil op in if
does not recognize it as a variable and the regular
adp variable regexp picks it up and tries to localize it.

see this commit for details.