Revision 74477782
Von Moritz Bunkus vor etwa 11 Jahren hinzugefügt
| SL/User.pm | ||
|---|---|---|
| 39 | 39 |
|
| 40 | 40 |
#use SL::Auth; |
| 41 | 41 |
use SL::DB::AuthClient; |
| 42 |
use SL::DB::Employee; |
|
| 42 | 43 |
use SL::DBConnect; |
| 43 | 44 |
use SL::DBUpgrade2; |
| 44 | 45 |
use SL::DBUtils; |
| ... | ... | |
| 126 | 127 |
my $update_available = $dbupdater->update2_available($dbh); |
| 127 | 128 |
$dbh->disconnect; |
| 128 | 129 |
|
| 129 |
return LOGIN_OK() if !$update_available; |
|
| 130 |
if (!$update_available) {
|
|
| 131 |
SL::DB::Manager::Employee->update_entries_for_authorized_users; |
|
| 132 |
return LOGIN_OK(); |
|
| 133 |
} |
|
| 130 | 134 |
|
| 131 | 135 |
$form->{$_} = $::auth->client->{$_} for qw(dbname dbhost dbport dbuser dbpasswd);
|
| 132 | 136 |
$form->{$_} = $myconfig{$_} for qw(datestyle);
|
| ... | ... | |
| 151 | 155 |
|
| 152 | 156 |
$self->dbupdate2(form => $form, updater => $dbupdater, database => $::auth->client->{dbname});
|
| 153 | 157 |
|
| 158 |
# If $self->dbupdate2 returns than this means all upgrade scripts |
|
| 159 |
# have been applied successfully, none required user |
|
| 160 |
# interaction. Otherwise the deeper layers would have called |
|
| 161 |
# ::end_of_request() already, and return would not have returned to |
|
| 162 |
# us. Therefore we can now use RDBO instances because their supposed |
|
| 163 |
# table structures do match the actual structures. So let's ensure |
|
| 164 |
# that the "employee" table contains the appropriate entries for all |
|
| 165 |
# users authorized for the current client. |
|
| 166 |
SL::DB::Manager::Employee->update_entries_for_authorized_users; |
|
| 167 |
|
|
| 154 | 168 |
SL::System::InstallationLock->unlock; |
| 155 | 169 |
|
| 156 | 170 |
print $form->parse_html_template("dbupgrade/footer");
|
Auch abrufbar als: Unified diff
Einträge in employee aus User->login heraus aktualisieren
Vor der Mandanteneinführung war User->login bereits hierfür
verantwortlich. Dann wurde diese Funktionalität in den
Login-Controller verschoben. Allerdings kehrt die Ausführung in exakt
einem Fall nicht zum Logincontroller zurück: wenn noch
Datenbankupgrades eingespielt werden müssen.
In dem Fall werden die Updates eingespielt, dem User wird die
"Weiter"-Seite angezeigt, und von hier aus geht es direkt zum
company_logo.
User->login weiß daher als einzige Instanz, wann alle DB-Upgrades
User->installiert sind, und damit, wann RDBO-Instanzen sicher genutzt
User->werden können.
Daher die Funktionalität in die Employee-Manager-Klasse verschoben und
das Triggern der Funktion aus dem Login-Controller wieder zurück nach
User->login verschoben.
Fixt #2361.