featured form-objects visible/unvisible

[kivitendo-erp.git] / SL / User.pm

diff --git a/SL/User.pm b/SL/User.pm
index 45f5f55..00c25d5 100644 (file)
--- a/SL/User.pm
+++ b/SL/User.pm
@@ -133,6 +133,11 @@ sub login {
     return LOGIN_OK();
   }
 
+  # Store the fact that we're applying database upgrades at the
+  # moment. That way functions called from the layout modules that may
+  # require updated tables can chose only to use basic features.
+  $::request->applying_database_upgrades(1);
+
   $form->{$_} = $::auth->client->{$_} for qw(dbname dbhost dbport dbuser dbpasswd);
   $form->{$_} = $myconfig{$_}         for qw(datestyle);
 
@@ -144,7 +149,7 @@ sub login {
 
   if ($form->{"show_dbupdate_warning"}) {
     print $form->parse_html_template("dbupgrade/warning", { unapplied_scripts => \@unapplied_scripts });
-    ::end_of_request();
+    $::dispatcher->end_request;
   }
 
   # update the tables
@@ -159,7 +164,7 @@ sub login {
   # If $self->dbupdate2 returns than this means all upgrade scripts
   # have been applied successfully, none required user
   # interaction. Otherwise the deeper layers would have called
-  # ::end_of_request() already, and return would not have returned to
+  # $::dispatcher->end_request already, and return would not have returned to
   # us. Therefore we can now use RDBO instances because their supposed
   # table structures do match the actual structures. So let's ensure
   # that the "employee" table contains the appropriate entries for all
@@ -449,7 +454,7 @@ sub get_default_myconfig {
     css_path     => 'css',      # Needed for menunew, see SL::Layout::Base::get_stylesheet_for_user
     dateformat   => $defaults->dateformat('dd.mm.yy'),
     numberformat => $defaults->numberformat('1.000,00'),
-    stylesheet   => 'kivitendo.css',
+    stylesheet   => $defaults->stylesheet('kivitendo.css'),
     timeformat   => $defaults->timeformat('hh:mm'),
     %user_config,
   );