240086 - Use names for group permissions instead of checkboxes

Status: RESOLVED WONTFIX

(Bugzilla :: Administration, task, P3)

Description

[Joel Peshkin]

If I have a site where a bug can be public, restricted to users of the product
(acme1000access), restricted to my own company (acme), or restricted to the
security team, (acmesecurity), I would currently have 3 checkboxes (8 possible
combinations) for group restrictions and confuse my users.

What I would like to do, if I define the names, is to have the UI use either a
single-select, radio buttons, etc...   to select
  Public
  Acme 1000 users
  Acme staff
  Acme security

and let the UI map between the human-understandable names and the individual
group permissions.

If I have 3 groups associated with a product, I will have at most 8 rows to fill
in.  In this example, I would have 
{acme1000users, acme, acmesecurity}, name
0 0 0, public
1 0 0, acme 1000 users
x 1 0, acme personnel (who are all known to be members of acme1000users as well)
x x 1, acme security (who are all know the be members of the other 2 groups)

Having done this, we can add additional information as well as the name field.
For example, we could identify the style to be used on buglist so that bz_secure
could be defined to correspond to public versus non_public one one site while it
corresponds to security team restrictions on another site.

This would require the addition of 2 new tables
1) permission_names
     id, 
     name, 
     style, ....
2) group_permission_map
     group_id,
     permission_id,
     value (1, 0, X) [it may be possible to skip storing any of the 0 records]

The SQL implications require a bit more thought.

Comment 1

[Dave Miller [:justdave]]

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.

Comment 2

[Joel Peshkin]

A question.....
If each group had a "level" associated with it, and we only paid attention to
the highest level, could we make this even simpler.  So, in the example...

If there are no two groups of the same level, we can really choose between the 4
groups.

010  Public (this group would be added just to keep this simple)
020  Acme 1000 users
030  Acme staff
040  Acme security

Comments?

Comment 3

[Tiago Mello [:timello]]

joel, where do you think is a good place to put a interface that will give the
possibility of map the group permissions in a simple name? Maybe on entry a new
bug? What about to define a parameters like usenamedgroups leaving this feature
optional?

Comment 4

[Joel Peshkin]

I think that the entry and edit forms for a bug would just replace the section
that starts with "Only users in all of the selected groups.." with a new
pick-one list.

The more complicated questions in my mind are...  
1)do we define the combinations on a per-product basis or a systemwide basis?
2)if we do this systemwide, how many distinct combinations that matter are there?

My point with number 2 is...  if I have a group of ProductXXX-developers and a
group for ProductXXX-security people and I know that all my security people are
also developers, I may have a chart like this...

dev secure  meaning
0    0      open to all
1    0      restricted to developers
0    1      restricted to security
1    1      restricted to security

However, the 0/1 case is redundant.  I really would rather replace 0/1 with X/1.
 Also, if the developers group is MANDATORY for the product, I really want to
only define
1/0 restricted to developers
1/1 restricted to security

Comment 5

[Tiago Mello [:timello]]

Joel, I think:
  1. Just replace the checkbox for a select box will solve this problem.
However, the groups names could still confusing the users (maybe a group alias
will solve);
  2. Avoid the complex combinations of groups on bug entry/edit, leaving this
hierarchy for the editgroups;
  3. Even with a mandatory group for a product, ignores it and show it in the
select box; (IMO, mandatory group is much obscure for users);

I think that there is no need for tables to solve this bug. Poke me if I'm
wrong, please.

Comment 6

[Tiago Mello [:timello]]

kiko, give us your comment, please. 

Comment 7

[Joel Peshkin]

(poke)

I am trying to solve 2 problems
1) Users are normally not aware of the group names and which ones matter and
which ones don't, so if there are 2 checkboxes, there are normally 3 options
that make sense, not 4 because one of the groups is usually a superset of the other.
2) A selection between "restrict to my_developers AND customer_log_access" and
"restrict to customer_log_access" is confusing.  I'd like that to say "Keep
private to my developers" versus "Share with customer"

 

Comment 8

[Tiago Mello [:timello]]

/me is with purple left eye :)

Joel, but:
  What about create super groups with names: "Keep
private to my developers" and "Share with customer". And then, edit these super
groups adding child groups to them. And them on edit group controls choose these
super groups as product group?. In this case, the select will work.

Group allowed to view this bug: [Public |v]
                                 |Share with customer    |
                                 |Keep private developers|

I have another eye. :).

Comment 9

[Christian Reis]

Indeed, there are three approaches here, both of which involve changing the
group selection to a select box:

  a) Structure your groups in a way that their names and structure provide the
correct restriction policy for your installation.

  b) Offer options that do all the possible permutations of sets of groups,
defining names for them.

  c) Define named "bug groups" that are a fixed, named set of groups.

Approaches a) and c) are similar and perhaps in keeping with what Joel is
suggesting in comment #2. In fact, was that were bug groups were originally
intended for?

Comment 10

[Gabriel Sales de Oliveira]

Joel, when you say style do you mean that will be possible to add somthing like
a skin to the bug?? So private bugs have a site that looks totally different of
public bugs site??

Comment 11

[Christian Reis]

Gabriel -- Joel means just for the buglist styling. We currently have a padlock
in private bugs; this could be changed (still using CSS) for bugs with certain
group restrictions.

Comment 12

[Joel Peshkin]

WRT comment 9:
  We don't want to have a distinct setting for each possible permutation since a
more restrictive group makes a less restrictive group into a don't-care.  We
need to have a way to define the "relevent" combinations and name those.

  Then, in addition to the names, we can take a cue from the same table that
assigns the name to a combination and use that cue to style both the padlock and
the bug's "skin"

Comment 13

[Gabriel Sales de Oliveira]

Joel and kiko, look at our idea:

1. Select all groups that belongs to the product.

2. For each one catch the related groups. 
(The number of related groups defines the hierarchy between the product groups)

3.tables: permissions_names
                id, name, style
          permissions_group_product_map
                perm_id, group_id, product_id

4. If group is in the lowest level prompt 'share with group'
   Intermediary ones prompt 'Restrict to + groups realted'
   Highest level  'Restrict to group'

For example A, B, C are our groups and the predefined messages:

Share with "groupA"           - lower hierarchy
Restrict to "groupB"/"groupC" - intermediary
Restrict to "groupC"          - higher

Comment 14

[Joel Peshkin]

(In reply to comment #13)

> 2. For each one catch the related groups. 
> (The number of related groups defines the hierarchy between the product groups)

I don't understand what this means.  Can you elaborate?

Comment 15

[Christian Reis]

Essentially, Gabriel was describing a way of detecting in runtime (i.e., at
show_bug.cgi time) what groups were included in others (and therefore, what
options to omit).

Spoke to Joel on the phone about this today. We hashed out some ideas and the
one that stuck best was the following.

  - Per-product, we'd have a group-combination-edit form.
  - This form would allow us to identify group combinations that applied to that
product, and name that group combination.
  - Bug restrictions would then rely on the named group combinations indicated,
instead of the actual bug groups. They would be listed in a single select box.
Group combinations without names would not be included in the list.

This would require a schema change (to save these group combinations). It avoids
needing to do in runtime recursive queries in the group hierarchy to identify
redundant combinations (we /could/ however do these queries in the edit
group-combination-edit form, and indicate in the UI that certain options were
redundant).

This is a proposal; let's say the "named-group-combinations" proposal.

Comment 16

[Christian Reis]

There is another solution, which may be too much work for large installations
<wink>. The solution involves:

  - Allowing only a single group (non-mandatory) to be specified for a bug.
Mandatory groups would be indicated by a label.
  - Restructure the group system somewhat to have the following properties:
    - Products have a set of groups
    - The Bugzilla installation would organize product groups in a way that
suggested the groups created applied only to that product -- perhaps we would
make the UI allow for very convenient product group creation (and group
aggregation inside them).
    - The Bugzilla administrator would create product groups and assemble them
from existing groups as necessary. The product groups are already named, and
their labels would be used in the group select box in show_bug.cgi.
   
This is a bit muddled with mandatory, but the advantage of this proposal is that
no additional schema needs to be added -- we are taking advantage of what we
currently have. 

Let's call this the "structured-group" proposal.

Comment 17

[Christian Reis]

The two proposals above are similar in effect and diverge in how they are
presented to the administrator, and how they are implemented in the DB schema. I
am happy to clarify or discuss either if necessary. Which should we push towards?

Comment 18

[Tiago Mello [:timello]]

Kiko, Joel
About "named-group-combinations" proposal, could we make this feature optional
adding a paramenter like usenamedgroups? It will have a little or no impact for
existent bugzilla instalattions.

Comment 19

[Joel Peshkin]

I like the "named-group" proposal.  It coule either be controlled by a parameter
or....  

if the administrator has not named a product's group combinations,
--> use checkboxes
if the administrator has names and group combinations for a product, 
--> select from among those names

The group naming control panel can prune out combinations that are totally
redundant.  This also makes it possible to omit definitions that are not
sensible for a particular site and make it possible to define names for group
combinations for some products while not doing so for others.

It does leave an interesting question with mass-change, though.  My inclination
would be to assume that anyone doing mass-change can handle the checkboxes. 

Comment 20

[Gabriel Sales de Oliveira]

Attachment: A first propose

Just a First proposal, 
"Edit named Groups" is On editproducts.cgi and the edition template keeps the
bugzilla table pattern. 

It's a good place??

Comment 21

[Gabriel Sales de Oliveira]

Attachment: Propose

I create editnamedgroup.cgi to list and create the named groups,
next step is the action edit.

Comment 22

[Joel Peshkin]

Comment on attachment 186348 [details] [diff] [review]
Propose

Seems a bit buggy :-(

Needed an edit before it even compiled.  Then, it is missing a ffooter template
required to make it work.

Comment 23

[Joel Peshkin]

Comment on attachment 186348 [details] [diff] [review]
Propose

see comment 22

Comment 24

[Gabriel Sales de Oliveira]

Attachment: Propose fixed

A Fixed patch, with the same code plus a footer template.

I create editnamedgroup.cgi to list and create the named groups,
next step is the action edit.

Comment 25

[Joel Peshkin]

Comment on attachment 186366 [details] [diff] [review]
Propose fixed

I think this is on the right track, but nothing happens when I add a new name.

Comment 26

[Joel Peshkin]

I'm not sure I like having a named_id in the bugs table.  The names are for
presentation in the UI, but the actual information is in the bug_group_map. 
Adding the name to the bugs table sounds a lot like cached information.  Is that
its intent?

Comment 27

[Tiago Mello [:timello]]

(In reply to comment #26)
> I'm not sure I like having a named_id in the bugs table.  The names are for
> presentation in the UI, but the actual information is in the bug_group_map. 
> Adding the name to the bugs table sounds a lot like cached information.  Is that
> its intent?
> 

Yes, it is cached information. We will use it to avoid a lot of queries and if
the named groups wont be optional like using a parameter, the bug_group_map
table will not exist anymore.

Comment 28

[Gabriel Sales de Oliveira]

Attachment: Enter new named group

Now the backend to add a named group is running.

Comment 29

[Joel Peshkin]

The group-name edit function does not seem to work yet.

Also, it seems to treat mandatory groups the same as shown groups. 

The edit_bug changes do not seem to be here yet, so it is hard to tell if this
is going to be able to handle cases like "the bug is a security bug, but the
current user is not in the security group and can see it because it is CC'd only"

I'm not sure if these issues are managable with the current approach yet.  Too
skeletal to tell, I think.

Comment 30

[Christian Reis]

(In reply to comment #29)
> The group-name edit function does not seem to work yet.

We'll have an updated patch up tomorrow.

> The edit_bug changes do not seem to be here yet,

Do you mean show_bug? 

> so it is hard to tell if this is going to be able to handle cases like "the 
> bug is a security bug, but the current user is not in the security group and 
> can see it because it is CC'd only

Could you rephrase this? I wonder if you're concerned about the UI we're going
to display in show_bug or something else.

Comment 31

[Joel Peshkin]

> 
> Do you mean show_bug? 
>
yes
 

> 
> Could you rephrase this? I wonder if you're concerned about the UI we're going
> to display in show_bug or something else.

yes.  I am wondering how to best handle the show_bug UI.

Comment 32

[Gabriel Sales de Oliveira]

Attachment: Named Groups

The basic system works, you can enter, edit or delete named groups, and if the
product has a named group set the bugs that belongs to the product have a
selectbox with the named groups.
Next Step:
-Implement the verification user->bug->groups according to the named groups
set;

-Implement the verification when select the groups of a named group(if the
select is redundant);

-Implement the bug count for the named groups.

Comment 33

[Joel Peshkin]

Comment on attachment 187153 [details] [diff] [review]
Named  Groups

I only played with this for the moment....

Well.  It fails with a "Cannot edit : no valid action was specified" error if I
try to edit named groups on a product that does not yet have any named groups. 
The eror happens after the footer, so it might just be a code fall-through.

Also, if I add a named group and try to edit it, I get a 
DBD::mysql::db selectcol_arrayref failed: Unknown column 'named_id' in 'where
clause' [for Statement "
	SELECT count(bug_id) FROM bugs
	WHERE named_id = ?"] at /xxx/bugzilla/editnamedgroups.cgi line 94
it looks like you are missing some checksetup code for upgraders.

Comment 34

[Gabriel Sales de Oliveira]

Attachment: Basic system

The basic systems works, plus with a help.
Next step:

- Validation bug system, and Group redundancy.
- Show Bug count.

Comment 35

[Joel Peshkin]

Comment on attachment 187289 [details] [diff] [review]
Basic system

This fails if a site from tip is update to use this patch.  You need to add
code to create named_id in the bugs table in checksetup.

Comment 36

[Gabriel Sales de Oliveira]

Attachment: Named group system

The system works, with the redundant group selection verification for the named
groups and the desired restrictions per user.

The only thing that does not work is the showbugcounts in the list of named
groups.

I need a review asap cause this patch is getting bitrotted all the time..

Comment 37

[Joel Peshkin]

Comment on attachment 190178 [details] [diff] [review]
Named group system


I'll do a bit more inspection on this when I get a chance, but it offers  group
combinations ("Public View") that are not legal  for a product with mandatory
groups even if there is no named group permitting that combination. 
Process_bug does not comply with the illegal combination, but it should not be
offered.

Also, there does not seem to be a way to edit the "style" column.

Comment 38

[Gabriel Sales de Oliveira]

Attachment: Don't display Public view when product had mandatory groups

When a product has mandatory groups only the created named groups will appear
as options at bug's named group selectbox.

I believe that style field could be handle in other bug, if the bug 240086 be
approved.

Comment 39

[Joel Peshkin]

Comment on attachment 191251 [details] [diff] [review]
Don't display Public view when product had mandatory groups

functions well, but it is customary to pass runtests :-(

Also, I dont see any place where editnamedgroups checks to ensure that it is
being called by an authorized user.

Also, there are some w3c validation regressions on editproducts (missing TR)



I'll continue to inspect this as well.

Comment 40

[Gabriel Sales de Oliveira]

Attachment: code updated version

I updated the code a lot and the functionality remain the same.

Comment 41

[Joel Peshkin]

Comment on attachment 192115 [details] [diff] [review]
code updated version

OK, this time I'll focus mostly on some light testing.

We don't need a special system group for this.	Use editcomponents to restrict
access to editnamedgroups.

Function prototypes are being removed from all the code in another bug which
should land bfore this does so please remove the function prototypes.

Bitrotted already....  CGI.pl is gone

I created a bug before "upgrading" to this patched version.  Even though that
bug was in a group, the acitivity log shows that, on my first edit, I changed
it from PUBLIC (which is illegal for the product) to one of my named groups.

editnamedgroups still has a validation problem.  (a </p> where there is no <P>
open ( <HR> closes an open <P> )

If I create a product with no group controls set, I still may want to name the
"public" setting so that I can pick up styling from it later.

The named group "public view" seems to be hard-coded somewhere.  This should be
just a named group that has no groups.

If I have a product that allows ANYONE to submit a bug and has SHOWN/SHOWN for
a group (so users can  restrict bugs to that group even if they are not members
of that group), a group member sees the named-group select list when creating a
new bug.  A non-member sees a checkbox instead of the select box.

When you test the next patch, don't forget to try the DEFAULT/SHOWN and
SHOWN/SHOWN combinations and similar scenarios.

Comment 42

[Gabriel Sales de Oliveira]

Attachment: v10-Bugs fixes

Public Named Group isn't anymore hardcoded so, when users create bugs the named
group selectbox start empty, the same happens with bugs with no named group
setted(bugs that had been created before the named groups).
As you select a named group the blank option dissapears.

When the product has SHOWN/SHOWN or SHOWN/DEFAULT groups don't seem a good
thing	 offer to a user the option to restrict the bug to a group that he
don't belong too what may cause a self contamination(if the user check the
checkbox he is not able to see or edit the bug), i made a "hack" to fix this
when named groups are setted so only users that belongs to the group can see
the selectbox with the named groups options.

Comment 43

[Gabriel Sales de Oliveira]

Attachment: v10-fixed

I Fix my mistake now when a group have SHOWN/SHOWN or SHOWN/DEFAULT controls,
all users are able to restrict the bug to that group.

Comment 44

[Joel Peshkin]

Comment on attachment 192979 [details] [diff] [review]
v10-fixed

I'm still focussing mostly on testing and this is not working smoothly.  I did
not even get as far as determining what happens when I have existing bugs and
change the named group rules or group controls.

I did this....
Created product with no groups

Named “Very Public” for no groups

Enter a new bug

Group select shows choice of blank (selected) or “Very Public” not selected. 
Should have been “Very Public” is only option (probably just show it rather
than putting it in a select box.

Submitted with the “blank” selected and when bug was processed, named group
stayed blank.  It should have selected the named group that matched the actual
settings. (Very Public)

Subsequently changed bug to select Very Public.  That changed the named group
in the activity log and, correctly,  did not change any corresponding groups.

Added a product “likebmo” with a group called “secure” which is SHOWN/SHOWN but
of which nobody is a member.

Created a bug and set it to be secure.	That works.

Created a named group “secure” and another “open” for the new product.

Redisplayed the already-entered bug.  It had the blank field selected (should
have been “secure”)

Entered a new bug and selected secure.	It was properly created, but it then
offers me the option to select secure .vs. open when I edit the bug.  When we
use checkboxes, the options that I am not permitted to use are correctly not
shown or, if already set, are greyed out.  The named groups offer me the option
of doing all sorts of things I am not permitted to do.

-----------

I also took a quick look at the code...

In User.pm, accessible_named_groups does not seem  to have any docs nor does
the named_groups() function in Product.pm

Why use a constant DB_COLUMNS instead of just using a qw[] with a list for the
columns??  It only seems to add another level of obfuscation.  Also, what keeps
the table name from becoming part of the key to the hash?

I am a bit confused by the namedgroups BLOCK in the edit template.  Does it 
take an argument??  How did the name attribute become simply “name” instead of
having a ‘.’ Within the hash key?

Comment 45

[Gabriel Sales de Oliveira]

Attachment: v11-Works like group controls

Now when the product has groups Shown/Shown Shown/Default Default/Default it
works like the checkboxes work.

The difference is when a user that doesn't belong to group open a bug and
choose public the selectbox is disabled instead of disapear (in the checkbox
way).

Comment 46

[Joel Peshkin]

Comment on attachment 193848 [details] [diff] [review]
v11-Works like group controls

This seems to work a lot better.  I need to do a lot more testing and a more
thorough reviews, but here's the beginning...

Runtests fails because Bugzilla.pm wont compile.  I'm not sure why this is.

 Bugzilla.pm: Constant subroutine Bugzilla::SHUTDOWNHTML_EXEMPT redefined at
/home/perl/local/lib/5.8.0/constant.pm line 108.




> # Steve Stock ([e-mail])
>-
> $dbh->bz_add_column('bugs', 'target_milestone', 
>                     {TYPE => 'varchar(20)', NOTNULL => 1, DEFAULT => "'---'"});
> $dbh->bz_add_column('bugs', 'qa_contact', {TYPE => 'INT3'});
>+$dbh->bz_add_column('bugs', 'named_id', 
>+                    {TYPE => 'INT3'});
> $dbh->bz_add_column('bugs', 'status_whiteboard', 
>                    {TYPE => 'MEDIUMTEXT', NOTNULL => 1, DEFAULT => "''"});

This needs to be in at the end of the --TABLE-- seciton.


When I change named group definitions, if I followed the sequence propely, the
existing bugs may not always get the appropriate name setting.	I need to try
this some more.  In any case, we probably need some type of sanitycheck.  The
queries for that will have to be written carefully so they don't take forever.

Comment 47

[Joel Peshkin]

Comment on attachment 193848 [details] [diff] [review]
v11-Works like group controls

see previous comment.  I'll keep testing in parallel tomorrow.

Comment 48

[Gabriel Sales de Oliveira]

Attachment: v11-fix No runtest errors

I change the checksetup.pl and delete a line at NamedGroup.pm that call
Bugzilla.pm that was causing runtests error.

Sorry about that...

Comment 49

[Joel Peshkin]

Comment on attachment 193939 [details] [diff] [review]
v11-fix No runtest errors


>Index: editnamedgroups.cgi
>===================================================================
>RCS file: editnamedgroups.cgi
>diff -N editnamedgroups.cgi
>--- /dev/null	1 Jan 1970 00:00:00 -0000
>+++ editnamedgroups.cgi	26 Aug 2005 16:59:35 -0000


When named group definitions change, how do the individual bugs get update?



>Index: enter_bug.cgi
>===================================================================
>RCS file: /cvsroot/mozilla/webtools/bugzilla/enter_bug.cgi,v
>retrieving revision 1.117
>diff -u -p -r1.117 enter_bug.cgi
>--- enter_bug.cgi	25 Aug 2005 14:02:40 -0000	1.117
>+++ enter_bug.cgi	26 Aug 2005 16:59:39 -0000
>@@ -59,6 +59,9 @@ use vars qw(
>   $classdesc
> );
> 
>+use Bugzilla::Product;
>+use Bugzilla::Group;
>+
> # If we're using bug groups to restrict bug entry, we need to know who the 
> # user is right from the start. 
> Bugzilla->login(LOGIN_REQUIRED) if AnyEntryGroups();
>@@ -576,6 +579,15 @@ while (MoreSQLData()) {
> 
>     push @groups, $group;        
> }
>+my $action = 'create';
>+my $user = new Bugzilla::User($userid);

Bugzilla->login should return this user object

>+my $product_obj = new Bugzilla::Product($product_id);
>+
>+my @accessible_named_groups = 
>+    $user->accessible_named_groups($product_obj, $action);
>+
>+$vars->{'named_groups'} = \@accessible_named_groups
>+    if scalar(@accessible_named_groups);
> 
> $vars->{'group'} = \@groups;
> 
>Index: post_bug.cgi
>===================================================================
>RCS file: /cvsroot/mozilla/webtools/bugzilla/post_bug.cgi,v
>retrieving revision 1.125

>+
>+foreach my $group (values %$group_controls) {
>+    if ($group->{'membercontrol'} eq CONTROLMAPMANDATORY &&
>+        $group->{'othercontrol'} eq CONTROLMAPMANDATORY) {
>+            $vars->{'mandatory_group'} = CONTROLMAPMANDATORY;
>+    }
>+}
>+

What is this section doing?  Is this for the showing of the bug just created? 
You only need to check memberscontrol for that.   The mandatory_group variable
never seems to get used anywhere.  Add a few more comments please.



>+    # Removes all groups from the bug and add the new ones.
>+    my $named_group_groups =
>+        Bugzilla::Group::get_groups_by_named_group($named_group);
>+    @groupAdd = keys %$named_group_groups;
>+
>+    if ($bug->{'named_id'}) {
>+        my $named_group_groups_old =
>+            Bugzilla::Group::get_groups_by_named_group($bug->{'named_id'});
>+        @groupDel = keys %$named_group_groups_old; 
>+    }

Won't this cause all the groups that are common to both the old and new
namedgroup to be both removed and added?

>Index: Bugzilla/Bug.pm
>===================================================================
>RCS file: /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Bug.pm,v
>retrieving revision 1.92
>diff -u -p -r1.92 Bug.pm
>--- Bugzilla/Bug.pm	23 Aug 2005 12:17:17 -0000	1.92
>+++ Bugzilla/Bug.pm	26 Aug 2005 16:59:44 -0000
>@@ -24,6 +24,7 @@
> #                 Dave Miller    <[e-mail]>
> #                 Max Kanat-Alexander <[e-mail]>
> #                 Frédéric Buclin <[e-mail]>
>+#                 Gabriel S. Oliveira <[e-mail]> 
> 
> package Bugzilla::Bug;
> 
>@@ -45,6 +46,7 @@ use Bugzilla::FlagType;
> use Bugzilla::User;
> use Bugzilla::Util;
> use Bugzilla::Error;
>+use Bugzilla::Product;
> 
> use base qw(Exporter);
> @Bugzilla::Bug::EXPORT = qw(
>@@ -77,7 +79,7 @@ sub fields {
>                     bug_file_loc status_whiteboard keywords
>                     priority bug_severity target_milestone
>                     dependson blocked votes
>-                    reporter assigned_to cc
>+                    reporter assigned_to cc named_id
>                    );
> 
>     if (Param('useqacontact')) {
>@@ -172,7 +174,7 @@ sub initBug  {
>       $dbh->sql_date_format('creation_ts', '%Y.%m.%d %H:%i') . ",
>       delta_ts, COALESCE(SUM(votes.vote_count), 0),
>       reporter_accessible, cclist_accessible,
>-      estimated_time, remaining_time, " .
>+      estimated_time, remaining_time, named_id, " .
>       $dbh->sql_date_format('deadline', '%Y-%m-%d') . "
>     FROM bugs
>        LEFT JOIN votes
>@@ -210,7 +212,8 @@ sub initBug  {
>                        "target_milestone", "qa_contact_id", "status_whiteboard",
>                        "creation_ts", "delta_ts", "votes",
>                        "reporter_accessible", "cclist_accessible",
>-                       "estimated_time", "remaining_time", "deadline")
>+                       "estimated_time", "remaining_time", "named_id",
>+                       "deadline")
>       {
>         $fields{$field} = shift @row;
>         if (defined $fields{$field}) {
>@@ -288,6 +291,21 @@ sub remove_from_db {
>     return $self;
> }
> 
>+# Update the groups that bug's belong by a named group change.
>+
>+sub update_bug_named_group {
>+    my $self = shift;
>+    my ($named_group_id) = @_;
>+    my $dbh = Bugzilla->dbh;
>+    
>+    my $bug_id = $self->{'bug_id'};
>+
>+    $dbh->do(q{UPDATE bugs SET named_id = ? WHERE bug_id = ?},
>+             undef, ($named_group_id, $bug_id));
>+
>+    return $self;
>+}
>+
> #####################################################################
> # Accessors
> #####################################################################
>@@ -591,6 +609,42 @@ sub groups {
>     return $self->{'groups'};
> }
> 
>+sub named_groups {
>+    my $self = shift;
>+    my $dbh = Bugzilla->dbh;
>+
>+    return $self->{'named_groups'} if exists $self->{'named_groups'};
>+    return undef if $self->{'error'};
>+    
>+    my $product = new Bugzilla::Product($self->{'product_id'});
>+    my @accessible_named_groups = 
>+        Bugzilla->user->accessible_named_groups($product);
>+    my $bug_groups = $self->groups;
>+    my @bug_groups_ids;
>+    foreach my $group (@$bug_groups) {
>+        push @bug_groups_ids, $group->{'bit'};
>+    }
>+   
>+    foreach my $named_group (@accessible_named_groups) {
>+        my $named_group_groups = $named_group->groups;
>+        
>+        my @named_groups_ids = [keys %$named_group_groups];
>+        
>+        if ($self->{'named_id'} == $named_group->named_id) {
>+            $named_group->{'checked'} = 1;
>+        } 
>+        elsif (!$self->{'named_id'} 
>+             && @bug_groups_ids eq @named_groups_ids) {
>+            $named_group->{'checked'} = 1;
>+        }
>+    }
>+    
>+    $self->{'named_groups'} = \@accessible_named_groups 
>+        if scalar(@accessible_named_groups);
>+
>+    return $self->{'named_groups'};
>+}
>+


What does this routine do and how does it differ from accessible_named_groups
??
> 
>+sub get_bugs_by_named_group ($) {
>+    my $named_id = shift;
>+    my $dbh = Bugzilla->dbh;
>+    my $vars = {};
>+ 
>+    unless (detaint_natural($named_id)) {
>+        $vars->{'named_id'} = $named_id;
>+        ThrowUserError("namedgroup_id_invalid", $vars);
>+    }
>+    my $bug_ids = $dbh->selectcol_arrayref(q{
>+        SELECT bug_id FROM bugs WHERE named_id = ?}, undef, $named_id);
>+   
>+    return $bug_ids;
>+}
>+

I dont think we want to get hundreds of thousands of bugs in one list.	If this
is just for a confirm-delete, use a count instead.

Comment 50

[Joel Peshkin]

One other thing.   We need to have a way to sanitycheck and mass-update group
names in the bugs table.  If we take the example of a product with group
controls A, B, and C possible (other than NA) and 

(1)open : none
(2)foo  : (100)A
(3)bar  : either (101)B or (A and B)
(4)baz  : (102)C

We **should** be able to generate SQL to 

UDPATE bugs 
  LEFT JOIN bug_group_map AS A
    ON bugs.id = A.bug_id AND A.group_id = 100
  LEFT JOIN bug_group_map AS B
    ON bugs.id = B.bug_id AND B.group_id = 100
  LEFT JOIN bug_group_map AS C
    ON bugs.id = C.bug_id AND C.group_id = 100
SET named_id = 1
  WHERE A.bug_id IS NULL AND B.bug_id IS NULL AND C.bug_id IS NULL

and the same for other combinations.  Note that we do have to deal with the
issue that "bar" is probably defined as B only but a bug that has both the A and
B groups would also be "bar"  (or we could identify that as an illegal condition
and sanitycheck for it)

We should might want to use the same logic within Bug.pm to load the named_id
from the bug_group_map instead of trusting whatever is cached in the table.

Comment 51

[Gabriel Sales de Oliveira]

(In reply to comment #49)
> (From update of attachment 193939 [details] [diff] [review] [edit])
> 
> >Index: editnamedgroups.cgi
> >===================================================================
> >RCS file: editnamedgroups.cgi
> >diff -N editnamedgroups.cgi
> >--- /dev/null	1 Jan 1970 00:00:00 -0000
> >+++ editnamedgroups.cgi	26 Aug 2005 16:59:35 -0000
> 
> 
> When named group definitions change, how do the individual bugs get update?

The bugs are not updated in the actual code, i'm changing that. :(

> 
> 
> 
> >Index: enter_bug.cgi
> >===================================================================
> >RCS file: /cvsroot/mozilla/webtools/bugzilla/enter_bug.cgi,v
> >retrieving revision 1.117
> >diff -u -p -r1.117 enter_bug.cgi
> >--- enter_bug.cgi	25 Aug 2005 14:02:40 -0000	1.117
> >+++ enter_bug.cgi	26 Aug 2005 16:59:39 -0000
> >@@ -59,6 +59,9 @@ use vars qw(
> >   $classdesc
> > );
> > 
> >+use Bugzilla::Product;
> >+use Bugzilla::Group;
> >+
> > # If we're using bug groups to restrict bug entry, we need to know who the 
> > # user is right from the start. 
> > Bugzilla->login(LOGIN_REQUIRED) if AnyEntryGroups();
> >@@ -576,6 +579,15 @@ while (MoreSQLData()) {
> > 
> >     push @groups, $group;        
> > }
> >+my $action = 'create';
> >+my $user = new Bugzilla::User($userid);
> 
> Bugzilla->login should return this user object

I'll change that
> 
> >+my $product_obj = new Bugzilla::Product($product_id);
> >+
> >+my @accessible_named_groups = 
> >+    $user->accessible_named_groups($product_obj, $action);
> >+
> >+$vars->{'named_groups'} = \@accessible_named_groups
> >+    if scalar(@accessible_named_groups);
> > 
> > $vars->{'group'} = \@groups;
> > 
> >Index: post_bug.cgi
> >===================================================================
> >RCS file: /cvsroot/mozilla/webtools/bugzilla/post_bug.cgi,v
> >retrieving revision 1.125
> 
> >+
> >+foreach my $group (values %$group_controls) {
> >+    if ($group->{'membercontrol'} eq CONTROLMAPMANDATORY &&
> >+        $group->{'othercontrol'} eq CONTROLMAPMANDATORY) {
> >+            $vars->{'mandatory_group'} = CONTROLMAPMANDATORY;
> >+    }
> >+}
> >+
> 
> What is this section doing?  Is this for the showing of the bug just created? 
> You only need to check memberscontrol for that.   The mandatory_group variable
> never seems to get used anywhere.  Add a few more comments please.

Sorry this is trash from a older patch, it was to template automatic select
named groups with mandatory groups unused now.

> 
> 
> 
> >+    # Removes all groups from the bug and add the new ones.
> >+    my $named_group_groups =
> >+        Bugzilla::Group::get_groups_by_named_group($named_group);
> >+    @groupAdd = keys %$named_group_groups;
> >+
> >+    if ($bug->{'named_id'}) {
> >+        my $named_group_groups_old =
> >+            Bugzilla::Group::get_groups_by_named_group($bug->{'named_id'});
> >+        @groupDel = keys %$named_group_groups_old; 
> >+    }
> 
> Won't this cause all the groups that are common to both the old and new
> namedgroup to be both removed and added?

Yeap, cause i think this is more quick then compare old and new named group groups
 
> 
> >Index: Bugzilla/Bug.pm
> >===================================================================
> >RCS file: /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Bug.pm,v
> >retrieving revision 1.92
> >diff -u -p -r1.92 Bug.pm
> >--- Bugzilla/Bug.pm	23 Aug 2005 12:17:17 -0000	1.92
> >+++ Bugzilla/Bug.pm	26 Aug 2005 16:59:44 -0000
> >@@ -24,6 +24,7 @@
> > #                 Dave Miller    <[e-mail]>
> > #                 Max Kanat-Alexander <[e-mail]>
> > #                 Frédéric Buclin <[e-mail]>
> >+#                 Gabriel S. Oliveira <[e-mail]> 
> > 
> > package Bugzilla::Bug;
> > 
> >@@ -45,6 +46,7 @@ use Bugzilla::FlagType;
> > use Bugzilla::User;
> > use Bugzilla::Util;
> > use Bugzilla::Error;
> >+use Bugzilla::Product;
> > 
> > use base qw(Exporter);
> > @Bugzilla::Bug::EXPORT = qw(
> >@@ -77,7 +79,7 @@ sub fields {
> >                     bug_file_loc status_whiteboard keywords
> >                     priority bug_severity target_milestone
> >                     dependson blocked votes
> >-                    reporter assigned_to cc
> >+                    reporter assigned_to cc named_id
> >                    );
> > 
> >     if (Param('useqacontact')) {
> >@@ -172,7 +174,7 @@ sub initBug  {
> >       $dbh->sql_date_format('creation_ts', '%Y.%m.%d %H:%i') . ",
> >       delta_ts, COALESCE(SUM(votes.vote_count), 0),
> >       reporter_accessible, cclist_accessible,
> >-      estimated_time, remaining_time, " .
> >+      estimated_time, remaining_time, named_id, " .
> >       $dbh->sql_date_format('deadline', '%Y-%m-%d') . "
> >     FROM bugs
> >        LEFT JOIN votes
> >@@ -210,7 +212,8 @@ sub initBug  {
> >                        "target_milestone", "qa_contact_id", "status_whiteboard",
> >                        "creation_ts", "delta_ts", "votes",
> >                        "reporter_accessible", "cclist_accessible",
> >-                       "estimated_time", "remaining_time", "deadline")
> >+                       "estimated_time", "remaining_time", "named_id",
> >+                       "deadline")
> >       {
> >         $fields{$field} = shift @row;
> >         if (defined $fields{$field}) {
> >@@ -288,6 +291,21 @@ sub remove_from_db {
> >     return $self;
> > }
> > 
> >+# Update the groups that bug's belong by a named group change.
> >+
> >+sub update_bug_named_group {
> >+    my $self = shift;
> >+    my ($named_group_id) = @_;
> >+    my $dbh = Bugzilla->dbh;
> >+    
> >+    my $bug_id = $self->{'bug_id'};
> >+
> >+    $dbh->do(q{UPDATE bugs SET named_id = ? WHERE bug_id = ?},
> >+             undef, ($named_group_id, $bug_id));
> >+
> >+    return $self;
> >+}
> >+
> > #####################################################################
> > # Accessors
> > #####################################################################
> >@@ -591,6 +609,42 @@ sub groups {
> >     return $self->{'groups'};
> > }
> > 
> >+sub named_groups {
> >+    my $self = shift;
> >+    my $dbh = Bugzilla->dbh;
> >+
> >+    return $self->{'named_groups'} if exists $self->{'named_groups'};
> >+    return undef if $self->{'error'};
> >+    
> >+    my $product = new Bugzilla::Product($self->{'product_id'});
> >+    my @accessible_named_groups = 
> >+        Bugzilla->user->accessible_named_groups($product);
> >+    my $bug_groups = $self->groups;
> >+    my @bug_groups_ids;
> >+    foreach my $group (@$bug_groups) {
> >+        push @bug_groups_ids, $group->{'bit'};
> >+    }
> >+   
> >+    foreach my $named_group (@accessible_named_groups) {
> >+        my $named_group_groups = $named_group->groups;
> >+        
> >+        my @named_groups_ids = [keys %$named_group_groups];
> >+        
> >+        if ($self->{'named_id'} == $named_group->named_id) {
> >+            $named_group->{'checked'} = 1;
> >+        } 
> >+        elsif (!$self->{'named_id'} 
> >+             && @bug_groups_ids eq @named_groups_ids) {
> >+            $named_group->{'checked'} = 1;
> >+        }
> >+    }
> >+    
> >+    $self->{'named_groups'} = \@accessible_named_groups 
> >+        if scalar(@accessible_named_groups);
> >+
> >+    return $self->{'named_groups'};
> >+}
> >+
> 
> 
> What does this routine do and how does it differ from accessible_named_groups
> ??

This Bugzilla::Bug Method is used to display the named group fiels at
show_bug.cgi, he add a flag('checked') to the named group received from
accessible_named_groups according the bug named_id or bug groups.

> > 
> >+sub get_bugs_by_named_group ($) {
> >+    my $named_id = shift;
> >+    my $dbh = Bugzilla->dbh;
> >+    my $vars = {};
> >+ 
> >+    unless (detaint_natural($named_id)) {
> >+        $vars->{'named_id'} = $named_id;
> >+        ThrowUserError("namedgroup_id_invalid", $vars);
> >+    }
> >+    my $bug_ids = $dbh->selectcol_arrayref(q{
> >+        SELECT bug_id FROM bugs WHERE named_id = ?}, undef, $named_id);
> >+   
> >+    return $bug_ids;
> >+}
> >+
> 
> I dont think we want to get hundreds of thousands of bugs in one list.	If this
> is just for a confirm-delete, use a count instead.

Ok.
> 
> 
> 
> 

Comment 52

[Joel Peshkin]

> > 
> > Won't this cause all the groups that are common to both the old and new
> > namedgroup to be both removed and added?
> 
> Yeap, cause i think this is more quick then compare old and new named group groups
>  

I think you still need to do the compare or the activity log will be a real mess.

Comment 53

[Gabriel Sales de Oliveira]

Attachment: v12-update bug groups

I changed the structure that named group groups are changed, and added the sub
update_bug_groups to change bug groups when changing named group groups.

Now I'm working in a way to show all the group possibilities to admin when
create named groups, i'm able to check just a pair of groups with sub
is_redundant and mount a hash table with them, handle with this hash maybe be a
mess...

If you have some idea on how to do this check please tell me :)

Comment 54

[Joel Peshkin]

Comment on attachment 195468 [details] [diff] [review]
v12-update bug groups

I only looked for the mechanisms to update named groups.  This still tries to
pull a list of ALL bugs using a particular named group and then check them. 
That won't work when the list gets to be hundreds  of thousands of bugs.

You need to generate queries (generate SQL) that look for bugs that need to be
changes and then either iterate through the results (fetching one number at a
time) updating the bugs or else use a subselect.

The SQL for the selection part of this needs to be something like....

SELECT bug_id FROM bugs
LEFT JOIN bug_group_map AS bgm_group12 ON bugs.bug_id = bgm_group12.bug_id
LEFT JOIN bug_group_map AS bgm_group15 ON bugs.bug_id = bgm_group15.bug_id
WHERE 
bugs.named_id <> 3 AND (bgm_group12.bug_id IS NOT NULL AND bgm_group15.bug_id
IS NULL)

Assuming that bugs that are in group12 and not in group15 are required to be in
named_id 3, this returns a list of bugs that need to be put in named_id 3.

If we can rely on mysql versions that support subselects, you can actually do
this using an UPDATE ... SELECT that sets the named_id to 3 for a list that
need to be set to 3.

This logic would need to go in the editnamedgroups cgi is well as in
sanitycheck.

A simpler version should figure out which named_id a bug should get as is is
being processed.  (processing should rely only on the group bits and then,
after those are validated, assign the named_id based on them)

I am still a bit concerned about the is_redundant approach because it does not
know if group inheritence is changed AFTER the names are assigned.  I would
still prefer that the person running editnamedgroups identify the ditinction
between groups that matter to an assignment and groups that are don't-cares for
the assignemnt.

Comment 55

[Gabriel Sales de Oliveira]

Attachment: v13-possible group combinations admin warning

The system checks if all possible product groups combinations are created in
the Named Groups and filter by group hiearchy.

I'm in doubt about the UI, have any suggestions ?

Bugs to fix:

1- filter combinations when a mandatory group is setted
2- warning when deleting a product group that is in a product named group
3- update named group groups when change a group control to Mandatory/Mandatory

4- change the get_x_by_y .pm functions.

Comment 56

[Joel Peshkin]

Comment on attachment 197748 [details] [diff] [review]
v13-possible group combinations admin warning

getting closer...

Runtest failed...  
not ok 133 - (en/default) template/en/default/admin/namedgroups/edit.html.tmpl
has unfiltered directives:
#   48: group.description FILTER
#	    html
# --ERROR


Also, I had a bug that was not in any groups, but, after loading the bug, it
had an incorrect group name.  Like I commented earlier, we should have support
for checking these in sanitycheck and figure them out from the bits as a bug is
loaded.  (only buglist should rely on the cached namedgroup and  that cached
namedgroup should be updated whenever we update group controls or named froup
definitions for a product and it should be checked by sanitycheck)

Comment 57

[Gabriel Sales de Oliveira]

Attachment: v13-fix sanitycheck and other bugs

Bugs fixed.

Is the sanitycheck good?

Comment 58

[Joel Peshkin]

See comment 54.  

Sanitycheck should check for bugs where the group in the bugs table does not
match the bug_group_map.   That can be done in one SQL statement per named_id to
identify bugs that have that named_id but do not meet the criteria plus one per
named_id to identify bugs that do meet the criteria but do nto have the named_id.

Whenever group controls or name definitions are changed, you want to use the
same SQL, but you act on the result rather than just reporting it.

Comment 59

[André Batosti]

Attachment: v14: all sanity checks

Comment 60

[Joel Peshkin]

Comment on attachment 197918 [details] [diff] [review]
v14: all sanity checks

This still updates bug groups for entire named groups based on the named group.
That is the opposite of what we should be doing.

The group name is NEVER the authoritative thing for security purposes.	The
only reason it exists in the bugs table at all is so that buglists can style
based on it.  Any other time, (security checks, policy checks, loading a bug,
etc...) we  look at a single bug's bug_group_map settings and infer the group
name.

When a named group is redefined, we don't change anything in bug_group_map. 
Rather, we must re-evaluate the bugs that think they have that named_id to
determine if they need to be reclassified into a differrent named_id and we
query for bugs that meet the criteria for that named_id but do not currently
have that named_id.  Those two queries should be 100% shared with what
Sanitycheck needs to do to detect any cases where there is a mismatch.

Comment 61

[Gabriel Sales de Oliveira]

Attachment: v14-improvements

We now have:
-Auto-update when creating a named group to fit bugs with matching group
combination.
-Sanitycheck for bugs without named groups and an option to fix it.
-Sanitycheck for bugs with wrong named group set

I have to work in a fine way to fix the bugs with wrong named groups and
perform a verification when groups inheritance was changed.

The possible group combinations stuff on editnamedgroups.cgi is good on that
way? O_o

Comment 62

[Gabriel Sales de Oliveira]

Attachment: v14-unbitroted

last version got bitroted by a lot of bug checkins

Comment 63

[Gabriel Sales de Oliveira]

Attachment: v14-fix

v14-fix

Comment 64

[André Batosti]

Attachment: v15 - sanity checks fix

Fixes for the sanity checks errors.

Comment 65

[Vlad Dascalu]

Comment on attachment 201771 [details] [diff] [review]
v15 - sanity checks fix

Hrm, how do we manage to let these kind of goodies expire?

This no longer applies to the trunk cleanly. It can probably be updated with minimal effort to apply to the trunk cleanly again.

If someone cleans it up, I'll make the time to do a review on it.

Comment 66

[Gabriel Sales de Oliveira]

Attachment: v16-unbitrot

It is a big patch :/

thanks for the interest vladd ;)

Comment 67

[Vlad Dascalu]

Comment on attachment 230571 [details] [diff] [review]
v16-unbitrot

Review is theoretically scheduled at the end of this week but things could pop up.

Frederic - could you help here with some review by any chance?

Comment 68

[Frédéric Buclin]

This is a huge patch. I will need some time to understand what joel wants and how gbel implements it, and read all comments to see if I miss something. Security bugs and QA tests have higher priority, so do not expect any review from me before the next set of releases (which should happen in September).

Comment 69

[Max Kanat-Alexander]

Okay, I've read most of this bug and I have some comments:

1) I don't understand what this bug is trying to do that can't currently be
   done with our normal groups system, other than just having the UI be different.

2) It seems like this whole bug is trying to solve the fact that we have AND
   groups when we should have OR groups.

At some point I was planning to restructure the entire permissions system to work this way:

1) All bugs are *denied* by default.
2) You may only access a bug if you are in a group that has access to it.
3) There is a group called called "Everybody" that always includes everybody.
4) You may access a bug if you are in *any* of its groups. (OR groups)

Does that solve the problem posed in this bug? I can't really understand, because the summary just wants a new UI. I think a new UI is sensible; I don't understand why we're going into all this complexity inside this bug.

Comment 70

[Gervase Markham [:gerv]]

Perhaps we need to take the necessary design discussion to the mailing list or newsgroup - this bug is pretty long already.

But I think the current permissions system has two features which make it really hard for people to understand, and which lead to a lot of support questions. They are the AND rather than OR nature of it, and the Mandatory/Allowed/etc. system. I'd support any change which looked to improve the situation in these two respects.

Gerv

Comment 71

[Frédéric Buclin]

If we move from the AND to OR logic, we will have to be *very* careful about current installations. This could make the upgrade really difficult.

Comment 72

[Max Kanat-Alexander]

(In reply to comment #71)
> If we move from the AND to OR logic, we will have to be *very* careful about
> current installations. This could make the upgrade really difficult.

  Yeah. That discussion and patch would happen in a different bug. After all, the summary of this bug is just a UI change...

Comment 73

[Frédéric Buclin]

Comment on attachment 230571 [details] [diff] [review]
v16-unbitrot

pushing this one out of my radar for now.

Comment 74

[Frédéric Buclin]

This bug is retargetted to Bugzilla 3.2 for one of the following reasons:

- it has no assignee (except the default one)
- we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1)
- it's not a blocker

If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0.

If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug.

If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".

Comment 75

[Frédéric Buclin]

Comment on attachment 230571 [details] [diff] [review]
v16-unbitrot

Highly bitrotten.

Comment 76

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set "blocking3.2" tp "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

Comment 77

[Frédéric Buclin]

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.

Comment 78

[Gervase Markham [:gerv]]

We've now implemented OR groups, which as comment 69 suggests, may well make this scenario much easier. If there's still more to do here, extract it and file a new bug.

Gerv