The mailing list for listmasters using Sympa

[Gerard Ranke <address@concealed>]

That seems right. Here's what I see in our exclusion_table:

+------------------+--------------+------+-----+---------+-------+
| Field            | Type         | Null | Key | Default | Extra |
+------------------+--------------+------+-----+---------+-------+
| date_exclusion   | int(11)      | YES  |     | NULL    |       |
| family_exclusion | varchar(50)  | NO   | PRI |         |       |
| list_exclusion   | varchar(57)  | NO   | PRI |         |       |
| robot_exclusion  | varchar(80)  | NO   | PRI |         |       |
| user_exclusion   | varchar(100) | NO   | PRI | NULL    |       |
+------------------+--------------+------+-----+---------+-------+


On 09/12/2016 07:06 PM, Amos (via sympa-users Mailing List) wrote:
> for this last one I just did:
> 
> ALTER TABLE exclusion_table MODIFY COLUMN family_exclusion VARCHAR(50)
> NOT NULL DEFAULT '';
> 
> 
> On Mon, Sep 12, 2016 at 11:44 AM, Amos <address@concealed
> <mailto:address@concealed>> wrote:
> 
>     well, i dropped the id_logs column from logs_table.  I'm guessing
>     that was missed because of skipping versions to 6.2.16.
> 
>     now seeing this:
> 
>     Unable to execute SQL statement "INSERT INTO exclusion_table
>     (list_exclusion, robot_exclusion, user_exclusion, date_exclusion)
>     VALUES (?, ?, ?, ?)": (HY000) Field 'family_exclusion' doesn't have
>     a default value
> 
> 
> 
>     On Mon, Sep 12, 2016 at 8:40 AM, Gerard Ranke <address@concealed
>     <mailto:address@concealed>> wrote:
> 
>         On 09/12/2016 02:59 PM, Amos (via sympa-users Mailing List) wrote:
>         > I notice Upgrade.pm has the following:
>         >
>         >     if (lower_version($previous_version, '6.2.10')
>         >         and not lower_version($previous_version, '5.3a.8')) {
>         >         $log->syslog('notice', 'Upgrading logs_table.');
>         >         my $sdm = Sympa::DatabaseManager->instance;
>         >
>         >         # As the field id_logs is no longer used but it has NOT 
> NULL
>         >         # constraint, it should be deleted.
>         >         if ($sdm and $sdm->can('delete_field')) {
>         >             $sdm->delete_field({table => 'logs_table', field => 
> 'id_logs'});
>         >         } else {
>         >             $log->syslog('err',
>         >                 'Can\'t delete id_logs field in logs_table.  You 
> must
>         > delete it manually.'
>         >             );
> 
>         I found no such message ( 'Can\'t delete id_logs field in
>         logs_table.
>         You must delete it manually.' ) in my logs. The log mentions a
>         mailmessage was sent with all the changes made, and I did indeed
>         receive
>         that. As far as I can see it mirrors the changes in the log. But no
>         mention of data_structure.version needing to be edited.
> 
>         However, my login issue was solved by pointing
>         SSLCACertificatePath to
>         /etc/ssl/certs in /etc/apache2/ssl-global.conf. ( /etc/ssl/certs is
>         where we have our CA certs. ) Thanks!
> 
>         gerard
> 
> 
> 
>

Attachment: signature.asc
Description: OpenPGP digital signature