I have tried the instructions given in 
http://roundup.sourceforge.net/doc-
0.7/customizing.html#editing-multiple-items-in-an-index-
view

and created a derived index 
template "issue.indexnew.html" (see attachment)

I am using it from an URL with filter parameters like

http://ors-x-wiki:8080/demo2/issue?
@template=indexnew&:sort=-
activity&:group=status&:filter=priority&:columns=id,activi
ty,title,creator,assignedto,status&priority=6

Now when I change values and press "Save Changes" 
the changes are done as expected, however an 
additional new issue is created as well. This is probably 
due to all the parameters from the original url that are 
submitted via 

<tal:block replace="structure request/indexargs_form" />

Even worse, if my filter includes multiple values, e.g. 
&priority=3,4,5,6 then I get a parser error.

Is there a way to prevent the index edit action from 
creating new issues.

I am using 0.6. and the instruction is for 0.7 - is this the 
reason and is there a "downgrade" available?

Kind regards,
Robert Seeger
robert DOT seeger AT usa DOT net

Logged In: YES 
user_id=6405

You have to use two separate <form>s - one for the index page 
arguments, and the other for editing. 
 
Note the last two lines of the first step in the instructions from 
the manual: 
 
1. add a form around the listing table, so at the top it reads:: 
 
    <form method="POST" tal:attributes="action 
request/classname"> 
     <table class="list"> 
 
   and at the bottom of that table:: 
 
     </table> 
    </form 
 
   making sure you match the ``</table>`` from the list table, 
not the 
   navigation table or the subsequent form table. 
 

Logged In: YES 
user_id=1102743

Thanks, Richard.
Indeed I had made a mistake with the scope of the form.
However correcting the form did not solve the problem.
So I had a deeper look into the coding of client.py and 
compared it with the implementation in 0.7.6.

I found that the reason for the additional issue was probably 
that the variable 'needed' in function Client._editnodes had an 
entry ('issue',None) that caused an implicit create action.
The reason for this had to be the form parsing routine that 
assumed default class and node id in some cases.
Further investigation showed an additional code block in 0.7.6 
in the form parsing routine (now in form_parser.py, but 
otherwise similar to Client.parsePropsFromForm):

            # skip implicit create if this isn't a create action
            if not create and nodeid is None:
                continue

As I did not want to fiddle with the function interface I had to 
set variable 'create' locally in the beginning of the function:

        create=1
        if form.has_key("@action"):
            create=(form.getvalue("@action")!="edit")
(which is probably not quite correct, but I only needed the 
patch for "edit")
However I still got an entry ('issue',None) in the form parsing 
result, probably due to:

        # we should always return something, even empty, for 
the context
        all_props[(default_cn, default_nodeid)] = {}

To fix this, I changed the 'skip implicit create' code block 
slightly into:

            # skip implicit create if this isn't a create action
            if not create and nodeid is None:
                try:
                    del all_props[this]
                except:
                    pass
                continue

Finally I adapted the redirection code at the end of 
client.editItemAction from its equivalent in 0.7.6:

        # redirect to the item's edit page
        # redirect to finish off
        url = self.base + self.classname
        # note that this action might have been called by an 
index page, so
        # we will want to include index-page args in this URL too
        if self.nodeid is not None:
            url += self.nodeid
        url += '?@ok_message=%s&@template=%s'%(urllib.quote
(message),
            urllib.quote(self.template))
        if self.nodeid is None:
            req = templating.HTMLRequest(self)
            url += '&' + req.indexargs_href('', {})[1:]
        raise Redirect, url

Now it seems to work as I want it, however I am not sure if 
this is the right way to patch it or if I might have broken 
something for other actions.
I have not tried if it works in 0.7 without modifications.

Kind regards,
Robert Seeger
robert DOT seeger AT usa DOT net    

Logged In: YES 
user_id=6405

Argh, sorry. I missed your note about using 0.6 
 
Bulk editing does not work in 0.6. You must upgrade to 0.7