Created attachment 979 [details]
diff -u of my current Conf.pm

Created attachment 980 [details]
diff -u of my current PerMsgStatus.pm

Michael -- any chance you could comment on the first patch?  it sounds useful
(although possibly better done in a cleaner way).

Subject: Re:  Changes to Configuration and Functionality

On Tue, Mar 16, 2004 at 09:51:49PM -0800, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> 
> ------- Additional Comments From jm@jmason.org  2004-03-16 21:51 -------
> Michael -- any chance you could comment on the first patch?  it sounds useful
> (although possibly better done in a cleaner way).
> 

The new custom SQL code should handle whatever you want to do, and if
not we'll fix it so that it does.

No need for the patch in my opinion.

Michael

Sorry guys, but how much cleaner do you want this?  It means no additional SQl 
parameters, just a different way of reading them in from the local.cf (or any 
other).  Having not been privy to the "new custom SQL code" I doubt that it 
could get any easier than this.  But I am willing to be wrong.  Probably makes 
everything you can do with the new SQl code possible with a single line in the 
local.cf as well.

The second patch is merely for a pedantic Company owner and is probably of no 
use to anyone.  I don't care if it never sees the light of day.

Subject: Re:  Changes to Configuration and Functionality

On Wed, Mar 17, 2004 at 12:47:36AM -0800, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> 
> ------- Additional Comments From jstevens@tusc.com.au  2004-03-17 00:47 -------
> Sorry guys, but how much cleaner do you want this?  It means no additional SQl 
> parameters, just a different way of reading them in from the local.cf (or any 
> other).  Having not been privy to the "new custom SQL code" I doubt that it 
> could get any easier than this.  But I am willing to be wrong.  Probably makes 
> everything you can do with the new SQl code possible with a single line in the 
> local.cf as well.

We no longer have code in Conf.pm that supports setting the table and
column names for the user prefs SQL config.  You can do so via the
user_scores_sql_custom_query config.  Here is the documentation
snippet for that feature, I think you will find it flexible and useful
enough for what you are trying to achieve:

=item user_scores_sql_custom_query query

This option gives you the ability to create a custom SQL query to
retrieve user scores and preferences.  In order to work correctly your
query should return two values, the preference name and value, in that
order.  In addition, there are several "variables" that you can use
as part of your query, these variables will be substituted for the
current values right before the query is run.  The current allowed
variables are:

=over 4

=item _TABLE_

The name of the table where user scores and preferences are stored, default
is userpref.

=item _USERNAME_

The current user's username.

=item _MAILBOX_

The portion before the @ as derived from the current user's username.

=item _DOMAIN_

The portion after the @ as derived from the current user's username, this
value may be null.

=back

The query must be one one continuous line in order to parse correctly.

Here are several example queries, please note that these are broken up
for easy reading, in your config it should be one continuous line.

=item Current default query:

SELECT preference, value FROM _TABLE_ WHERE username = _USERNAME_ OR username =
'@GLOBAL' ORDER BY username ASC

=item Use global and then domain level defaults:

SELECT preference, value FROM _TABLE_ WHERE username = _USERNAME_ OR username =
'@GLOBAL' OR username = '@~'||_DOMAIN_ ORDER BY username ASC

=item Maybe global prefs should override user prefs:

SELECT preference, value FROM _TABLE_ WHERE username = _USERNAME_ OR username =
'@GLOBAL' ORDER BY username DESC

=cut


You can then fairly easily write the optimal query for however you
have your preference data stored in the database.

Michael

Thanks.  But it seems like an awful lot of trouble to go to, when all that was 
needed was the ability to read to the endo of the line so a select query could 
be entered as the table_name.  But in any case, this is more than what I 
require.  From which version of SA does this apply?  I have not upgraded since 
2.54, which is working fine.

Subject: Re:  Changes to Configuration and Functionality

On Wed, Mar 17, 2004 at 03:26:57PM -0800, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> http://bugzilla.spamassassin.org/show_bug.cgi?id=1931
> 
> 
> 
> 
> 
> ------- Additional Comments From jstevens@tusc.com.au  2004-03-17 15:26 -------
> Thanks.  But it seems like an awful lot of trouble to go to, when all that was 
> needed was the ability to read to the endo of the line so a select query could 
> be entered as the table_name.

It was exactly this kluge that lead to the custom sql solution.  What
you see as overkill we see as the ability to support an infinite
number of variations on the same thing.

> But in any case, this is more than what I 
> require.  From which version of SA does this apply?  I have not upgraded since 
> 2.54, which is working fine.
> 

3.0.0

Michael

As per Michael, fixed in 3.0.0