This site is maintained for archival purposes only. Eclipse projects have transitioned to GitHub and Eclipse GitLab. Use the Projects search tool to locate your project and access its latest code and issue tracker.
Bug 180876 - [upstream][patch] support setting the visibility group for bugs when usevisibilitygroups is enabled
Summary: [upstream][patch] support setting the visibility group for bugs when usevisib...
Status: ASSIGNED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Mylyn (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 enhancement with 6 votes (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL: https://bugzilla.mozilla.org/show_bug...
Whiteboard:
Keywords:
: 228871 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-04-04 03:07 EDT by Thomas Ehrnhoefer CLA
Modified: 2011-09-30 16:07 EDT (History)
5 users (show)

See Also:

Attachments
method to get the group security information (1.22 KB, text/plain)
2008-05-29 13:55 EDT, Shawn Minto CLA 		no flags Details
mylyn/context/zip (1.36 KB, application/octet-stream)
2008-06-03 23:30 EDT, Frank Becker CLA 		no flags Details
patch (10.06 KB, patch)
2008-06-13 18:03 EDT, Frank Becker CLA 		no flags Details | Diff
mylyn/context/zip (131.74 KB, application/octet-stream)
2008-06-13 18:03 EDT, Frank Becker CLA 		no flags Details
revised patch (9.34 KB, patch)
2008-08-13 19:28 EDT, Robert Elves CLA 		no flags Details | Diff
patch V3 (22.50 KB, patch)
2010-03-17 17:10 EDT, Frank Becker CLA 		no flags Details | Diff
mylyn/context/zip (7.29 KB, application/octet-stream)
2010-03-17 17:10 EDT, Frank Becker CLA 		no flags Details
screenshot of the UI (94.36 KB, image/jpeg)
2010-03-17 17:11 EDT, Frank Becker CLA 		no flags Details
correted patch V3 (23.57 KB, patch)
2010-03-18 16:07 EDT, Frank Becker CLA 		no flags Details | Diff
mylyn/context/zip (19.06 KB, application/octet-stream)
2010-03-18 16:07 EDT, Frank Becker CLA 		no flags Details
Show Obsolete (2) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Ehrnhoefer CLA 2007-04-04 03:07:25 EDT 
Build ID: M20070212-1330

Steps To Reproduce:
1. Define groups for visibility in your own bugzilla and enter a bug with the usevisibilitygroup setting enabled
2. Open this Bug using Mylar, change something (e.g. add a comment) and submit it
3. View the bug in Bugzilla again and the usevisibilitygroup setting is now disabled. Mylar was not even showing this option.


More information:

From what I posted at the newsgroup:

We are using group settings in bugzilla to "hide" bugs from certain users (like the customer, who should only see bugs related to him).
 
But since I am using Mylar, we have more and more bugs without a group setting (the setting is called "Only users in all of the selected groups can view this bug:", a checkbox.
 
I found 2 issues when using Mylar:
1) I can't set this checkbox in Mylar (since it is not part of the editor)
2) Mylar resets the group setting. I opened a bug, which had the checkbox enabled, in Mylar, wrote a comment and submitted it. Then I checked in Bugzilla and the checkbox was disabled now.
 
SO Mylar does not show this element, but changes it.
 
Anybody knows about this? I looked briefly into the Mylar Bugzilla connector bugs but did not find anything. But before posting a new bug I wanted to check here first (or should I, if something came up again, simply post a bug report?).
 
greetings
Thomas
Comment 1 Thomas Ehrnhoefer CLA 2007-04-12 06:28:52 EDT 
But is it really an enhancement? Mylar is not only not supporting this setting in den rich editor, it deselects all group settings.

I tried it out again today and added comments to a bug from mylars editor, browser and my own web browser. If done from mylar editor, all checked groups boxes are unchecked afterwards.
Comment 2 Mik Kersten CLA 2007-04-12 12:11:45 EDT 
Good point.  The fact that Mylar is unchecking it means that this is a defect.
Comment 3 Robert Elves CLA 2007-04-14 16:40:08 EDT 
There appear to be a few hurdles to support groups:

1) Groups options are not supplied in the Bugzilla config rdf
2) Submission of group has uses an unusual name scheme "bit-16" which is not provided in the bug xml nor does there appear to be any logical mapping to this bit-# scheme.

I'll file these with Bugzilla.org next week. One out here might be the web service api so will look at that as well.
Comment 4 Robert Elves CLA 2007-04-24 19:56:02 EDT 
Submitted bug report targeting both issues mentioned in comment#3 above
https://bugzilla.mozilla.org/show_bug.cgi?id=378681

Updated mylar FAQ noting this (current) limitation:
http://wiki.eclipse.org/index.php/Mylar_FAQ#Known_limitations
Comment 5 Robert Elves CLA 2007-06-21 17:34:57 EDT 
Still awaiting feedback on https://bugzilla.mozilla.org/show_bug.cgi?id=378681.  Have commented there to elicit more feedback.
Comment 6 Robert Elves CLA 2007-07-24 12:15:05 EDT 
Still no response. If you're watching this report, consider voting for https://bugzilla.mozilla.org/show_bug.cgi?id=378681
Comment 7 Bernhard Merkle CLA 2007-11-27 04:29:41 EST 
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
Comment 8 Robert Elves CLA 2008-04-07 20:19:09 EDT 
Frank, do we have any other options here? Does the new Bugzilla web service api give us what we need to make this work?
Comment 9 Frank Becker CLA 2008-04-10 02:56:15 EDT 
 (In reply to comment #8)
> Frank, do we have any other options here? Does the new Bugzilla web service api
> give us what we need to make this work?

Sorry, I can say if this help until I have solved my problems with the bz_webservice_demo.pl. Currently I get there not the expected response.
Comment 10 Frank Becker CLA 2008-04-27 11:38:13 EDT 
 (In reply to comment #8)
> Frank, do we have any other options here? Does the new Bugzilla web service api
> give us what we need to make this work?

Sorry to say that but there is currently no way to get the needed information with the Bugzilla web service api.

Think we must wait until https://bugzilla.mozilla.org/show_bug.cgi?id=378681 is solved. Maybe it helps if we have more votes on this.
Comment 11 Robert Elves CLA 2008-04-30 11:51:19 EDT 
Okay thanks for investigating Frank.
Comment 12 Robert Elves CLA 2008-04-30 12:01:42 EDT 
*** Bug 228871 has been marked as a duplicate of this bug. ***
Comment 13 Shawn Minto CLA 2008-05-29 13:55:15 EDT 
Created attachment 102699 [details]
method to get the group security information

Here is a method that screen scrapes bugzilla to get the current group security information so that it can be sent back (thus stopping it from being cleared on submit).  If you want to use this, I can provide a test for it.
Comment 14 Frank Becker CLA 2008-05-30 02:06:44 EDT 
 (In reply to comment #13)
> Created an attachment (id=102699)
> method to get the group security information
> 
> Here is a method that screen scrapes bugzilla to get the current group security
> information so that it can be sent back (thus stopping it from being cleared on
> submit).  If you want to use this, I can provide a test for it.
Sorry, I think that we can not use this because actually we get the Information not by parsing HTML we use XML.
Comment 15 Robert Elves CLA 2008-05-30 12:45:39 EDT 
(In reply to comment #13)
> Created an attachment (id=102699)
> method to get the group security information
> 
> Here is a method that screen scrapes bugzilla to get the current group security
> information so that it can be sent back (thus stopping it from being cleared on
> submit).  If you want to use this, I can provide a test for it.

Thanks Shawn. I'll work this into the bugzilla client and test it out.

(In reply to comment #14)
> Sorry, I think that we can not use this because actually we get the Information
> not by parsing HTML we use XML.

True, but in order to work around this limitation, we could use the code Shawn provided to grab the information we need from the html in order to just retain the group security information upon submission.  This of course comes at the expense of an additional request but this would only be done when group security information is detected in the xml.  It isn't an ideal solution but would at least prevent clearing of group security information.
Comment 16 Frank Becker CLA 2008-05-30 16:34:11 EDT 
 (In reply to comment #15)

> True, but in order to work around this limitation, we could use the code Shawn
> provided to grab the information we need from the html in order to just retain
> the group security information upon submission.  This of course comes at the
> expense of an additional request but this would only be done when group security
> information is detected in the xml.  It isn't an ideal solution but would at
> least prevent clearing of group security information.

Rob, the Milestone is 3.1 so should I look into this bug after 3.0 is out?
Comment 17 Robert Elves CLA 2008-06-03 15:03:38 EDT 
Frank, if you have time to look at this for 3.0 that would be great.  Should just be a matter of checking in BugzillaClient.postTaskData() if the task data has a group attribute associated with it. If present, grab the ids using Shawn's patch and include them in the post.
Comment 18 Frank Becker CLA 2008-06-03 23:30:50 EDT 
(In reply to comment #17)
> Frank, if you have time to look at this for 3.0 that would be great.  Should
> just be a matter of checking in BugzillaClient.postTaskData() if the task data
> has a group attribute associated with it.
Rob, does this mean that we should change getTaskData to get all the information from HTML and no longer from XML?
Or
Should we double the postFormData to do XML and HTML(only for the group information)

> If present, grab the ids using Shawn's
> patch and include them in the post.
Comment 19 Frank Becker CLA 2008-06-03 23:30:55 EDT 
Created attachment 103486 [details]
mylyn/context/zip
Comment 20 Robert Elves CLA 2008-06-04 15:34:22 EDT 
(In reply to comment #18)
> Rob, does this mean that we should change getTaskData to get all the information
> from HTML and no longer from XML?

No, just do an extra html request upon posting if a group attribute is present in the task data.
Comment 21 Frank Becker CLA 2008-06-04 22:07:08 EDT 
(In reply to comment #20)
> No, just do an extra html request upon posting if a group attribute is present
> in the task data.

Sorry  how do you think that a group attribute comes into the task data. The only way I see is to do an other request with result stream HTML during getTaskData

Or did you mean that the additional request with result stream HTML should be done during postTaskData
Comment 22 Robert Elves CLA 2008-06-04 23:11:36 EDT 
(In reply to comment #21)
> Or did you mean that the additional request with result stream HTML should be
> done during postTaskData
Yes, I think if a group attribute is present, when posting and update, we can sneak in an html get, grab the ids,and include them in the post.
Comment 23 Frank Becker CLA 2008-06-05 00:07:46 EDT 
(In reply to comment #22)
> (In reply to comment #21)
> > Or did you mean that the additional request with result stream HTML should be
> > done during postTaskData
> Yes, I think if a group attribute is present, when posting and update, we can
> sneak in an html get, grab the ids,and include them in the post.
> 

Excuse, maybe I am a little bit silly because I am ill. But where did I know that a group attribute exists.
For my that sounds like the hen egg problem. What was first? 

The hen?

or

The egg?

This means where should I implement the HTML request for getting the group attribute. 

Implementing this in getTaskData means that we have two requests every time. Because we did not know if an administrate  change the usage of the group attribute.

For me if looks like it is better to do the additional  HTML request only during every postTaskData.
Comment 24 Robert Elves CLA 2008-06-05 01:41:03 EDT 
(In reply to comment #23)
> For me if looks like it is better to do the additional  HTML request only during
> every postTaskData.
Yes, this should only take place upon posting (BugzillaClient.postTaskData()).  It should only do so if the taskData passed to that method has a BugzillaAttribute.GROUP present, i.e.:

taskData.getRoot().getMappedAttribute(BugzillaAttribute.GROUP.getKey()) != null

If this attribute is present, then we know there are groups set on the report. In this case, we need to get the html for the bug report and grab those group ids as per the patch.
Comment 25 Frank Becker CLA 2008-06-06 14:56:02 EDT 
(In reply to comment #24)
> 
> taskData.getRoot().getMappedAttribute(BugzillaAttribute.GROUP.getKey()) != null
> 
> If this attribute is present, then we know there are groups set on the report.
> In this case, we need to get the html for the bug report and grab those group
> ids as per the patch.

OK but where is the mapped Attribute set? I can not find it in the source.
Comment 26 Robert Elves CLA 2008-06-06 16:42:51 EDT 
(In reply to comment #25)
> (In reply to comment #24)
> >
> > taskData.getRoot().getMappedAttribute(BugzillaAttribute.GROUP.getKey()) !=
> null
> >
> > If this attribute is present, then we know there are groups set on the report.
> > In this case, we need to get the html for the bug report and grab those group
> > ids as per the patch.
> 
> OK but where is the mapped Attribute set? I can not find it in the source.

If a bug report has a group selected, this attribute will be available on the taskData already being passed in to the postTaskData() method.

> taskData.getRoot().getMappedAttribute(BugzillaAttribute.GROUP.getKey()) != null

We get this much from the xml. What we don't get are the strange "bit-16" values you only find in the html bug form.  These are the values we need to grab and include in our post.
Comment 27 Frank Becker CLA 2008-06-07 02:47:28 EDT 
(In reply to comment #26)
> 
> We get this much from the xml. What we don't get are the strange "bit-16"
> values you only find in the html bug form.  These are the values we need to
> grab and include in our post.
> 

With Bugzilla 3.1.4 I see the bit-  only if I use show_bug.cgi?id=1 but with show_bug.cgi?id=1&ctype=xml I did not find bit-

In config.cgi?ctype=rdf I did not see the bit- .

What did I miss?
Comment 28 Robert Elves CLA 2008-06-12 03:45:54 EDT 
Running short on time here due to release train so have committed patch based on our discussion.
Comment 29 Frank Becker CLA 2008-06-13 18:03:47 EDT 
Created attachment 104924 [details]
patch

This patch use an other way to implement this.

Now the bit get test while
Comment 30 Frank Becker CLA 2008-06-13 18:03:54 EDT 
Created attachment 104925 [details]
mylyn/context/zip
Comment 31 Robert Elves CLA 2008-06-16 14:53:54 EDT 
This is great approach Frank. Lets apply this improvement for 3.0.1.
Comment 32 Robert Elves CLA 2008-07-15 19:53:54 EDT 
Sorry for not getting to this for 3.0.1 Frank.  We can review for the next release.
Comment 33 Robert Elves CLA 2008-08-13 18:39:11 EDT 
Looking at this now Frank...
Comment 34 Robert Elves CLA 2008-08-13 19:28:13 EDT 
Created attachment 109949 [details]
revised patch

This is looking great Frank. We just need to figure a way to avoid the double http request for each retrieval of task data.  I added the condition to check if a group attribute exists (similar to how it currently works) but this only works if a group has been selected.  One option might be to add a 'retrieve group security' button to the section and have it force the double retrieval.  But before we try that, lets see if we can think up some other options.
Comment 35 Frank Becker CLA 2008-08-18 16:35:50 EDT 
(In reply to comment #34)
> Created an attachment (id=109949)
> revised patch
> 
> This is looking great Frank. We just need to figure a way to avoid the double
> http request for each retrieval of task data.  I added the condition to check if
> a group attribute exists (similar to how it currently works) but this only works
> if a group has been selected.  One option might be to add a 'retrieve group
> security' button to the section and have it force the double retrieval.  But
> before we try that, lets see if we can think up some other options.
Patch is looking good!

What is to add a new flag to the configuration like the "local user enabled" in "Additional Settings" and add/remove the group flag in all tasks for the selected repository?
Comment 36 Robert Elves CLA 2008-09-09 16:37:32 EDT 
Although there are no negative side effects now when group visibility is used, we didn't converge on a rich editing solution that didn't result in performance penalty. We will continue to work towards a desirable solution in the next release cycle.
Comment 37 Robert Elves CLA 2008-09-09 16:42:20 EDT 
(In reply to comment #35)
> (In reply to comment #34)
> > Created an attachment (id=109949)
> > revised patch
> >
> > This is looking great Frank. We just need to figure a way to avoid the double
> > http request for each retrieval of task data.  I added the condition to check
> if
> > a group attribute exists (similar to how it currently works) but this only
> works
> > if a group has been selected.  One option might be to add a 'retrieve group
> > security' button to the section and have it force the double retrieval.  But
> > before we try that, lets see if we can think up some other options.
> Patch is looking good!
> 
> What is to add a new flag to the configuration like the "local user enabled" in
> "Additional Settings" and add/remove the group flag in all tasks for the
> selected repository?
Something along these lines might work. We could make this a setting as you suggest, then get the available group options as needed (if not already downloaded). Once we have them they could just be updated along with subsequent repository configuration updates (using some known bug id).  Then they could be presented with all tasks (without requiring two round trips each time).  Ideally though we should get this information from the repository configuration rdf.
Comment 38 Robert Elves CLA 2008-12-03 13:46:20 EST 
Rather than delving into the potential work arounds, since this is no longer a show stopper, we should try to motivate the necessary changes in Bugzilla:

378681: Bug XML only contains group names, while process_bug only accepts group IDs
https://bugzilla.mozilla.org/show_bug.cgi?id=378681
Comment 39 Frank Becker CLA 2010-03-15 15:40:04 EDT 
Now we must wait until https://bugzilla.mozilla.org/show_bug.cgi?id=552480 is fixed.

I create a patch when I have finished this.
Comment 40 Frank Becker CLA 2010-03-17 17:10:28 EDT 
Created attachment 162354 [details]
patch V3

Patch to save the current state. We can use this when Buzilla has a fix.
Comment 41 Frank Becker CLA 2010-03-17 17:10:58 EDT 
Created attachment 162355 [details]
mylyn/context/zip
Comment 42 Frank Becker CLA 2010-03-17 17:11:58 EDT 
Created attachment 162356 [details]
screenshot of the UI
Comment 43 Frank Becker CLA 2010-03-18 16:07:44 EDT 
Created attachment 162467 [details]
correted patch V3

Messages.java and messages.properties are now included
Comment 44 Frank Becker CLA 2010-03-18 16:07:55 EDT 
Created attachment 162468 [details]
mylyn/context/zip
Comment 45 Steffen Pingel CLA 2011-09-27 17:29:06 EDT 
Frank, can you summarize the status of this bug? If we are still planning to add this support it would be great to update the patch and push it into a code review.
Comment 46 Frank Becker CLA 2011-09-30 16:07:18 EDT 
(In reply to comment #45)
> Frank, can you summarize the status of this bug? If we are still planning to
> add this support it would be great to update the patch and push it into a code
> review.

We need to wait until https://bugzilla.mozilla.org/show_bug.cgi?id=449139 is fixed!