Changing my email address should automatically update saved queries.




User Accounts
15 years ago
9 years ago


(Reporter: Antonio M. D'souza, Unassigned)




(1 attachment, 1 obsolete attachment)



15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.0.1) Gecko/20021003
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.0.1) Gecko/20021003

I had saved a few queries that used my email address, since that is the globally
unique key for Bugzilla. When the new ability to change email addresses was
added to Bugzilla, I took advantage of it. Unfortunately, doing that did not
update the old email address used in my saved queries so now they are either
broken or useless because that address no longer exists in the DB. 

Reproducible: Always

Steps to Reproduce:
1. Create account.
2. File bug.
3. Create custom query using email addy & save the query.
4. change email address for account.
5. Try to use the saved query.
Actual Results:  
In one case (querying for bugs I had fixed) the query broke. In all others it
simply returned nothing. 

Expected Results:  
It should have done a search'n'replace on the saved queries when I changed email
oooh, I never thought of that, but that's absolutely right.

That wouldn't be a bad idea at all...  should be pretty easy to implement, too.
Severity: minor → enhancement
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Summary: Changing my email address does not automatically update the one used for saved queries. → Changing my email address should automatically update saved queries.
Target Milestone: --- → Bugzilla 2.18
This is true for renaming everything ...  stored queries (and charts?) probably
need to be converted over to IDs.

Comment 3

15 years ago
*** Bug 171882 has been marked as a duplicate of this bug. ***

Comment 4

15 years ago
Created attachment 129281 [details] [diff] [review]
Patch version 1 to update stored queries on email address change

In lieu of changing queries to use ids, which is the best way to go, this is
what seems to work for me, and updates stored queries on an email change (by a
user or by an admin)

Comments welcome to resolve any of the questions listed in the patch...

Comment 5

15 years ago
Created attachment 129351 [details] [diff] [review]
Patch version 2 to update stored queries on email address change

This version updates *all* the instances in a stored query, and not just the
Attachment #129281 - Attachment is obsolete: true
*** Bug 217497 has been marked as a duplicate of this bug. ***

Comment 7

15 years ago
One quick thing to note about the attached patch for any potential reviewer:
there is a missing PopGlobalSQLState() near the end of the UpdateNamedQuery()
routine. I will fix that with any other required changes post-review.

Comment 8

15 years ago
Comment on attachment 129351 [details] [diff] [review]
Patch version 2 to update stored queries on email address change

Gavin, can you update to use the new DBI interface? It's past time for that,
and it's really pretty simple.

Yes, you should check for exact matches to avoid the foo_bar vs. foo email
account issue -- remember, there's and and their user's
ubiquitous prefixes and sufixes.

I suspect *all* named queries should be updated.

Listing the queries updated could be fun, but if we're updating everybody's
queries it could be a violation of privacy, and it's not essential here anyway.

You're right, if you had a stored query that based itself on a substring of the
login name, the update will fail. There's no way around that, just document it

It's surprising that you had two different symbols for @ in namedqueries, but
yes, you should deal with both.

I don't know about locking, will ask bbaetz.
Attachment #129351 - Flags: review?(jake) → review-

Comment 9

15 years ago
Bradley, can you advise on the locking question Gavin posed?

+# 8) The LOCKing of tables needs work. tokens.cgi locks other tables, so 
+#    requires either this routine to do some locking, or for the tokens.cgi 
+#    caller to lock our namedqueries table. edituser.cgi does no locking. 
+#    Need to think about

I'm curious about this too; how should it be done?
I'm not convinced this is a good plan, because it creates inconsistency.
Currently, we don't touch stored queries (or stored charts, for that matter)
when things like email addresses, product names, or anything else changes.
"Fixing up" after one sort of change but not another would cause a lot of confusion.

So, you ask, why not fix them all? IMO, it would be both impossible, and
dangerous to try. You could never get everything, because of the substring and
regexp problem, and there's a danger that a loose update would corrupt someone's
query. It's also possible that people don't want their queries updated (e.g.
component foo becomes bar, and a new component foo gets created.)

If we wanted a stable form of storing queries, we'd store them as SQL, with
everything converted to userids, productids etc. But if we do that, we can't
convert back to a URL easily, and so people can't edit their queries.

IMO, the right way to deal with this issue is to make it easier to "edit" a
stored query - i.e. by saving the edited query back on top.



Comment 11

15 years ago
I'd agree that this would introduce some inconsistency from a
developer/administrator point of view, but it would also improve the Bugzilla 
experience for the end-user. I think it is reasonable for them to assume that
any of their own stored queries they have set up which match exacton their old
address would be updated. For an end-user, they cannot update products or
components, or keywords, so they will not see any inconsistency, will they?

I do have a slight privacy/security concern about updating other peoples queries
though. (i.e. If I have a query which includes an exact match on someone else's
email address, and they change their address, is it OK for Bugzilla to update my
stored query?) 

I could add a checkbox to the 2 places which change the email address saying 

'Update all stored queries which do an exact match for the old address?'

if people prefer.
see also bug 233617 (anything that fixes this is likely to be able to be
stretched to apply to that, too)
I absolutely think this should be fixed...  I just changed my email address and
confirmed it and everything, and I found this problem...  I also promptly found
that it is not possible to change it back.  I might be doing something wrong,
but this should be easily undoable.  This is probably a different bug, but I
also also no longer search for bugs that I am CC'd on.
(Sorry for spamming the bug)

Update: There was an email in my old inbox with a link to undo the change, which
I of course used.  Until this bug (and the other one I mentioned) is fixed, I
won't be able to move away from Yahoo! Mail (and it's 4MB limit) to a roomier
75MB mailbox I have been given.  Again, really sorry for spamming the bug :(.

Comment 15

14 years ago
*** Bug 235608 has been marked as a duplicate of this bug. ***
From the previous comments, it looks like some people aren't happy if bugzilla
changes the email address in stored queries when an email changes.

I've just changed my email, and as such, I now one of my saved queries does not
work - the name <> is not a valid username. It says to go back to change and try
again, but I can't do that as it's a saved one.

Why not provide a link to edit search there on the error page so that I can at
least edit or delete it so that I haven't got a useless search hanging around?
Or if that isn't possible, how about somewhere in preferences allowing me to
delete unwanted searches?

Just some thoughts...
enhancements without current patches are being pushed to 2.20
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
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.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
*** Bug 262633 has been marked as a duplicate of this bug. ***

Comment 20

14 years ago
That's the wrong fix....

use pronouns (bug 244239) to refer to yourself.

Comment 21

14 years ago
typed too fast...  I meant bug 226434
you can use %user% to refer to yourself (always)

Comment 22

14 years ago
how about a go back and edit your query link when a query fails, and if the 
user is logged in present edit and edit saved queries.

Comment 23

14 years ago
I think this should get a band-aid and a WONTFIX.
The page.cgi?id=saved-searches.html link and %user% solution avoids this.

Comment 24

14 years ago
(In reply to comment #21)
> typed too fast...  I meant bug 226434
> you can use %user% to refer to yourself (always)

this only works in the boolean charts though.

Comment 25

14 years ago
Let's figure out where else we need it and do a further enhancment to add
support there.  The key issue is we only want to do it for cases where we
couldn't mean anything else by %string%


13 years ago
Assignee: myk → user-accounts
QA Contact: mattyt-bugzilla → default-qa
Target Milestone: Bugzilla 2.22 → ---

Comment 26

12 years ago
*** Bug 354656 has been marked as a duplicate of this bug. ***

Comment 27

12 years ago
Is the problem with the ownership of the searches? Or with the old email addresses being searched for? I just encountered the problem of using searches after an address change.

If the latter is the problem (email address not in database), there would be no need to search and replace, just edit the search to search for the new address or the old address. This problem would exist in references to others formerly in the database who decided to close their accounts. If you wanted to look up bugs by after Joe Jones closed his bugzilla account, the search would flag an error because that addy no longer is active. If verification of valid addresses is a must, then maybe keep a database of old (changed) addresses and cancelled addresses that are referenced in old bug reports.

Would it be better to search-and-replace, or to keep old addresses on file?


10 years ago
Blocks: 110007


9 years ago
No longer blocks: 110007
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 110007
You need to log in before you can comment on or make changes to this bug.