Closed
Bug 192052
Opened 21 years ago
Closed 15 years ago
Changing my email address should automatically update saved queries.
Categories
(Bugzilla :: User Accounts, enhancement)
Bugzilla
User Accounts
Tracking
()
RESOLVED
DUPLICATE
of bug 110007
People
(Reporter: mozilla, Unassigned)
References
Details
Attachments
(1 file, 1 obsolete file)
6.88 KB,
patch
|
kiko
:
review-
|
Details | Diff | Splinter Review |
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 addys.
Comment 1•21 years ago
|
||
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
Status: UNCONFIRMED → NEW
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
Comment 2•21 years ago
|
||
This is true for renaming everything ... stored queries (and charts?) probably need to be converted over to IDs.
*** Bug 171882 has been marked as a duplicate of this bug. ***
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...
This version updates *all* the instances in a stored query, and not just the first.
Attachment #129281 -
Attachment is obsolete: true
Comment 6•21 years ago
|
||
*** Bug 217497 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Attachment #129351 -
Flags: review?(jake)
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•21 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 hotmail.com and yahoo.com 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 clearly. 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•21 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?
Comment 10•21 years ago
|
||
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. Thoughts? Gerv
Comment 11•21 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.
Comment 12•20 years ago
|
||
see also bug 233617 (anything that fixes this is likely to be able to be stretched to apply to that, too)
Comment 13•20 years ago
|
||
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.
Comment 14•20 years ago
|
||
(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•20 years ago
|
||
*** Bug 235608 has been marked as a duplicate of this bug. ***
Comment 16•20 years ago
|
||
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...
Comment 17•20 years ago
|
||
enhancements without current patches are being pushed to 2.20
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Comment 18•20 years ago
|
||
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
Comment 19•20 years ago
|
||
*** Bug 262633 has been marked as a duplicate of this bug. ***
Comment 20•20 years ago
|
||
That's the wrong fix.... use pronouns (bug 244239) to refer to yourself.
Comment 21•20 years ago
|
||
typed too fast... I meant bug 226434 you can use %user% to refer to yourself (always)
Comment 22•20 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•20 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•20 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•20 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%
Assignee: myk → user-accounts
QA Contact: mattyt-bugzilla → default-qa
Target Milestone: Bugzilla 2.22 → ---
Comment 26•18 years ago
|
||
*** Bug 354656 has been marked as a duplicate of this bug. ***
Comment 27•18 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 JoeJones@obsoletedomain.com 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?
Updated•15 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•