User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 Build Identifier: Firefox 2.0.0.3 Our client (eclipse.org/mylar) strictly makes use of the xml dump to make changes to existing bug reports. Unfortunately, groups are provided in the xml without any reference to the id/name used in the show_bug.cgi html such as "bit-16". There doesn't appear to be any guide to reproduce these ids client side when posting updates. Without this internal id/name mapping we are unable to post the groups information correctly resulting in loss of previously flagged groups on the bug report. Secondly, the group options are not provided in the configuration rdf dump. This also makes working with groups outside of html difficult since we cannot display what groups are available to choose from. Reproducible: Always Steps to Reproduce: 1.View the xml dump of a bug report and notice that only group tag is provided without internal id/name mapping necessary to update the bug 2. View config.cgi rdf output is missing available groups

Old, potentially related bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=275386

You are reporting two bugs here, one about importxml.pl and another one about config.cgi. The one about importxml.pl is invalid as exporting the bug data to another DB means the group ID is probably different. What is relevant is the group name. About groups being displayed in config.cgi, we should probably only restrict them to groups you belong to as some groups may be confidential. If you want the config.cgi part of your request to be addressed, please change the summary of this bug, else close it as INVALID.

(In reply to comment #2) > You are reporting two bugs here, one about importxml.pl and another one about > config.cgi. The one about importxml.pl is invalid as exporting the bug data to > another DB means the group ID is probably different. What is relevant is the > group name. In our use case, we're trying to submit an update to a regular bug (via process_bug.cgi) back to the remote repository but don't have the id/name required for form submission (because all we have to work with is what we get in the xml).

To clarify, we're submitting back to the same Bugzilla repository the data came from, not another database.

Any chance of getting feedback on comment#3 and 4?

with mylyn and groupsecurity enabled this is IMO a showstopper, because each modification on the mylyn side (or any other client, that uses bugzilla xml) _resets_ the group access rights on the bug. The only workaround is to disable the rich editor and use the browser option. please add the groupsecurity information into the xml

As additional comment, deskzilla (a bugzilla rich desktop client) now _supports_ group visibility, but I assume that they somehow parse the html on the client side and do not rely on bugzilla s xml format. http://almworks.com/deskzilla/

Okay, so this is two bugs. One is that process_bug only understands ids for groups, not their names, while we only publish their names in the XML. This would of course be fixed in the XML-RPC interface when we have Bug.update(), but in the mean time we should do something about it. I'm morphing this bug to just address that fact. The other bug is that config.cgi doesn't contain info about what groups are valid in which products. I've filed bug 449139 for that.

Is this on the radar for 3.4? This combined with bug#449139 would make the group functionality in the Mylyn editor complete.

tip: Checking in template/en/default/bug/show.xml.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/show.xml.tmpl,v <-- show.xml.tmpl new revision: 1.32; previous revision: 1.31 done 3.4.2: Checking in template/en/default/bug/show.xml.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/show.xml.tmpl,v <-- show.xml.tmpl new revision: 1.29.2.3; previous revision: 1.29.2.2 done

The trouble with fixing it this way is that it makes clients keep track of both names and numbers. (In other words, a group becomes an object with a collection of properties rather than just a simple string.) A cleaner interface would be for clients to use only the names, and have process_bug accept either names or numbers on input. Is there any possibility of that? Gerv

Names can change; IDs can't. I think using IDs makes more sense for stability purposes.

I agree with reed. I think the way I did it is better than relying on names in process_bug.cgi.

OK; I will update the API to use group objects, containing both names and IDs. Gerv