Revision 4555e130
Von Sven Schöling vor etwa 14 Jahren hinzugefügt
SL/CVar.pm | ||
---|---|---|
337 | 337 |
|
338 | 338 |
do_statement($form, $sth, $query, @values); |
339 | 339 |
|
340 |
unless ($params{always_valid}) { |
|
341 |
$self->save_custom_variables_validity(trans_id => $params{trans_id}, config_id => $config->{id}, |
|
342 |
validity => ($params{variables}->{"$params{name_prefix}cvar_$config->{name}$params{name_postfix}_valid"} ? 1 : 0) |
|
343 |
); |
|
344 |
}; |
|
340 |
my $valid_index = "$params{name_prefix}cvar_$config->{name}$params{name_postfix}_valid"; |
|
341 |
$self->save_custom_variables_validity(trans_id => $params{trans_id}, config_id => $config->{id}, |
|
342 |
validity => ($params{variables}{$valid_index} || $params{always_valid} ? 1 : 0) |
|
343 |
); |
|
345 | 344 |
} |
346 | 345 |
|
347 | 346 |
$sth->finish(); |
Auch abrufbar als: Unified diff
Bugfix: CVar Sichtbarkeit in Projekten.
Dieser Patch behebt zwei unabhängige Bugs, die dazu geführt haben, dass CVars
für Projekte nicht bearbeitbar waren.
Der erste ist, dass CVars für Projekte nicht vom validiersystem betrofen sind,
und deshalb always_valid geflaggt sein müssen. Das zweite hat verhindert, dass
bereits bestehende invalid flags gelöscht werden, wenn ein always_valid Objekt
seine CVars speichert. Normalerweise ist das kein Problem, muss hier aber
passieren für die Backwards Kompatibilität.