Closed
Bug 286357
Opened 20 years ago
Closed 20 years ago
user preference settings only works if all users sets non-default values for all settings
Categories
(Bugzilla :: User Accounts, defect)
Bugzilla
User Accounts
Tracking
()
RESOLVED
FIXED
Bugzilla 2.20
People
(Reporter: altlist, Assigned: altlist)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 4 obsolete files)
2.79 KB,
patch
|
altlist
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041223 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041223 Firefox/1.0
Best I can tell, profile_settings is setup to only contain non-default setting
values, such that the database size doesn't get too big.
However, this doesn't work for me, or at least with mysql-4.1.3. If a user A
sets a non-default value for a setting, all other users who opted for the
default value will automatically get the value selected by user A.
For a test case, I did below based on User/Setting.pm.
mysql> select * from setting;
+--------------------+------------------+------------+
| name | default_value | is_enabled |
+--------------------+------------------+------------+
| display_quips | on | 1 |
| comment_sort_order | oldest_to_newest | 1 |
+--------------------+------------------+------------+
2 rows in set (0.00 sec)
mysql> select * from profile_setting;
+---------+--------------------+------------------+
| user_id | setting_name | setting_value |
+---------+--------------------+------------------+
| 1 | display_quips | off |
| 2 | comment_sort_order | newest_to_oldest |
+---------+--------------------+------------------+
2 rows in set (0.00 sec)
The command below should return 2 rows, but only returns the row specifically
tied to userid=1.
mysql> select user_id, name, default_value, is_enabled, setting_value from
setting left join profile_setting on setting.name = profile_setting.setting_name
where profile_setting.user_id=1 or profile_setting.user_id=NULL;
+---------+---------------+---------------+------------+---------------+
| user_id | name | default_value | is_enabled | setting_value |
+---------+---------------+---------------+------------+---------------+
| 1 | display_quips | on | 1 | off |
+---------+---------------+---------------+------------+---------------+
1 row in set (0.01 sec)
Reproducible: Always
Steps to Reproduce:
Assignee | ||
Comment 1•20 years ago
|
||
Here's an initial patch that solves my specific problem. But I believe the
new() function also needs to be fixed.
In any case, I think this is a blocker for the 2.20 release.
Comment 2•20 years ago
|
||
Frederic helped me with the code on this, so I'm blaming him (and cc:ing him).
:)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•20 years ago
|
||
Right, nothing ever = NULL.
Assignee: user-accounts → altlst
Flags: blocking2.20?
Target Milestone: --- → Bugzilla 2.20
Updated•20 years ago
|
Attachment #177624 -
Flags: review?(travis)
Assignee | ||
Comment 4•20 years ago
|
||
Here's a cleaner implementation. The new() function still needs to be updated.
I suggest removing the large "if" code that auto-fetches the undefined
function parameters. I don't think that code is being used anywhere.
Attachment #177624 -
Attachment is obsolete: true
Attachment #177662 -
Flags: review?(travis)
Comment 5•20 years ago
|
||
(In reply to comment #4)
> I suggest removing the large "if" code that auto-fetches the undefined
> function parameters. I don't think that code is being used anywhere.
It is not, yet I'm not removing it. See discussion of this same point on bug
98123 for why.
Review within the next day or two.
Updated•20 years ago
|
Attachment #177624 -
Flags: review?(travis)
Comment 6•20 years ago
|
||
(In reply to comment #2)
> Frederic helped me with the code on this, so I'm blaming him (and cc:ing him).
>
(00:35:53) LpSolit: travis: I did what??? :)
(00:36:04) travis: I've got the logs to prove it, if you make me.
(00:36:07) travis: IRC logs, that is.
(00:36:14) LpSolit: yeah... show me :)
(00:38:10) travis: okay, I take it back
(00:38:24) travis: I found the conversation I was remembering, and it was about
a different bug. Sorry Fred!
(00:39:42) LpSolit: I want a comment in the bug to mention that I'm innocent :-p
(00:39:47) travis: lol
Updated•20 years ago
|
Flags: blocking2.20? → blocking2.20+
Comment 7•20 years ago
|
||
+ $user_id=0 if (! defined $user_id);
+
Please change this to:
$user_id = $user_id || 0;
Jouni taught me that one; it's much more elegant and succinct, and is what
people are moving too all over Bugzilla.
This version does look much better/cleaner than the first. I will try it out in
the morning and confirm that it works; if so, and if you can change that above,
I'll give it an r+.
Status: NEW → ASSIGNED
Comment 8•20 years ago
|
||
Albert, I understand from our e-mail correspondence that you're fixing this for
new() also... are you doing that on this bug? If so, I won't review until your
next patch is up; just let me know.
Assignee | ||
Comment 9•20 years ago
|
||
Here you go! I've updated the new() function per our discussions we've had
offline.
Attachment #177662 -
Attachment is obsolete: true
Attachment #177919 -
Flags: review?(travis)
Updated•20 years ago
|
Attachment #177662 -
Flags: review?(travis)
Assignee | ||
Updated•20 years ago
|
Attachment #177919 -
Flags: review?(shane.h.w.travis) → review?(mkanat)
Comment 10•20 years ago
|
||
>Please change this to:
> $user_id = $user_id || 0;
Even better: $user_id ||= 0;
Severity: normal → critical
Assignee | ||
Comment 11•20 years ago
|
||
(In reply to comment #10)
> >Please change this to:
> > $user_id = $user_id || 0;
>
> Even better: $user_id ||= 0;
Is this the only thing preventing the patch from getting approved? Any other
issues?
Assignee | ||
Comment 12•20 years ago
|
||
Minor update per comment #10
Attachment #177919 -
Attachment is obsolete: true
Attachment #182107 -
Flags: review?(mkanat)
Assignee | ||
Updated•20 years ago
|
Attachment #177919 -
Flags: review?(mkanat)
Comment 13•20 years ago
|
||
I tried this latest patch and received this output:
[root@bugzilla bugzilla]# patch -b -p0 <bug-286357-user-preference
patching file Bugzilla/User/Setting.pm
Hunk #2 FAILED at 137.
Hunk #4 FAILED at 170.
2 out of 5 hunks FAILED -- saving rejects to file Bugzilla/User/Setting.pm.rej
[root@bugzilla bugzilla]#
Comment 14•20 years ago
|
||
Comment on attachment 182107 [details] [diff] [review]
v4
OK, this looks good, but you also have to update the POD docs for get_defaults.
Please do post another patch with the updates, don't just fix it on checkin.
But you can carry forward r+.
Attachment #182107 -
Flags: review?(mkanat) → review+
Comment 15•20 years ago
|
||
Comment on attachment 182107 [details] [diff] [review]
v4
Oh, also, this patch is bitrotted.
Assignee | ||
Comment 16•20 years ago
|
||
Cleaned up, per comment #14 and comment #15. And I hate it when a patch gets
bitrotted in just 1 day! :)
Attachment #182107 -
Attachment is obsolete: true
Attachment #182114 -
Flags: review+
Assignee | ||
Updated•20 years ago
|
Flags: approval?
Updated•20 years ago
|
Flags: approval? → approval+
Comment 17•20 years ago
|
||
Checking in Bugzilla/User/Setting.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/User/Setting.pm,v <-- Setting.pm
new revision: 1.3; previous revision: 1.2
done
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•