Upgrade to 4.3 Now I'm Stumped

tombellin

After a morning fighting through configuration errors, I've stumbled into an issue I have absolutely no idea how to solve. This happens after clicking on the Perform Update button. This is all the information the error provides.
An error occurred during the upgrade:
Unknown column 'log27.project_id' in 'field list'

I suspect this is related to a bad update/install from the 3.xx series. I can't even figure out where the actual code for the update is that's generating this error.

Is there a way to figure out what the issue is and maybe get TBG to ignore this error and continue?

Thanks!

zegenie

David tombellin
FYI: If you're able to complete the actual upgrade but just aren't able to log in, you can use the tbg_cli command line script to change the user password of your admin account. Assuming the upgrade actually completed properly, you should now be able to log in.

zegenie

This can happen if the upgrade routine haven't been able to upgrade the logs table correctly. Which version are you upgrading from -> to?

David

Ok, i'm at the same point:
I'm upgrading from v4.1.0 free version to v4.3.0

Admin password

At the first time, i have entered a password with 5 characters.
When i click Perform Upgrade button, an error dialog appears saying at least "8 characters required" (something like that).

I'm going back with clicking the okay button.

Next time, i entered a bigger password but the Perform Upgrade button doesn't want to be active.

I looked into the code:

<input id="upgrade_password_admin" name="admin_password" class="adminpassword" placeholder="Enter a new admin password here" onkeyup="if ($(this).getValue().length >= 5 && **$('confirm_backup').checked) { $('start_upgrade').enable(); } else { $('start_upgrade').disable(); }">

And i put an alert to debug it.
I found that the $('confirm_backup').checked never be true elsewhere the value of the corresponding hidden input is always set to 1.

<input type="hidden" name="perform_upgrade" value="1">
<input type="hidden" name="confirm_backup" value="1" id="confirm_backup">

=> I used the F12 Chrome function and i added the checked tag to the perform_upgrade input and confirm_backup input to force this step and the upgrade process starts right.

<input type="hidden" name="perform_upgrade" value="1" checked>
<input type="hidden" name="confirm_backup" value="1" id="confirm_backup" checked>

Documentation dead link

The link upgrade notes contained into the wizard is dead.

Log error

Now, the upgrade process displays another error.

An error occurred during the upgrade:
Unknown column 'log53.project_id' in 'field list'

I clicked Okay button to go back to the process beginning, and i clicked forward to reach the last wizard page which says remove upgrade file.

I attempt to login as admin but i cannot.

Do i have to purge password into the Database or something like that ?

David

@zegenie @tombellin
I'm upgrading from v4.1.0 free version to v4.3.0 over RHEL 7 / PHP 7.2

Ok, i made a new upgrade from scratch (from the backup of my orignal database in v4.1.0).
I switched to the CLI mode to attempt to do the full process.

I 'touch' a file named upgrade
I check if my 'installed' file refers the good version
I launch ./tbg_cli upgrade
=> It performs a successfull upgrade to the 4.1.13 before logging an error.

---------------------
An error occured during the upgrade:
Unknown column 'log27.project_id' in 'field list'
---------------------

I update the installed file to 4.1.13 (in order to do not restart from the 4.1.0 elsewhere the upgrade process displays 'Duplicate columns' errors)
>cat installed
```
4.1.13, upgraded 18.03.2019 15:03
4.1, upgraded 27.01.2017 16:27
4.1, installed 27.05.2016 11:51
```
I comment the update which generate the error to test
sudo nano core/modules/installation/Upgrade.php

 protected function _upgradeFrom4dot1dot13()
    {
        $user_sessions_table = UserSessions::getTable();
        $this->cliEchoCreateTable($user_sessions_table);
        $user_sessions_table->create();

        if (framework\Context::isCLI()) {
            Command::cli_echo("Updating/fixing status of milestones.\n");
        }
        $milestones = tables\Milestones::getTable()->selectAll();
        #foreach ($milestones as $milestone)
        #{
            # $milestone->updateStatus();
            # $milestone->save();
        #}

I launch ./tbg_cli upgrade again

Performing upgrade: 4.1.13 -> 4.3.0

Gathering information before upgrading...


We're continuously adjusting and improving user security. As a result, this version changes the way passwords are handled and stored.
All users will require password resets after the upgrade process, and application-specific passwords must be regenerated.

Because of the improved password handling, we need to set a password for the admin account admin
New password for user with username admin (min 8 characters): administrator
Creating table thebuggenie\core\entities\tables\UserSessions
Updating/fixing status of milestones.
Updating/fixing article types.
Fixing file scopes.
Fixing issue spent times scopes.
Implementing new workflows.
100%
Successfully upgraded to version 4.2.0
Creating table thebuggenie\core\entities\tables\Branches
Creating table thebuggenie\core\entities\tables\Commits
Creating table thebuggenie\core\entities\tables\CommitFiles
Creating table thebuggenie\core\entities\tables\BranchCommits
Creating table thebuggenie\core\entities\tables\CommitFileDiffs
Creating table thebuggenie\core\entities\tables\IssueCommits
Creating table thebuggenie\core\entities\tables\LivelinkImports
Upgrading table thebuggenie\core\entities\tables\LogItems
Upgrading table thebuggenie\modules\mailing\entities\tables\IncomingEmailAccounts
Fixing issue spent times scopes.
Successfully upgraded to version 4.3.0

And the installed file is automatically updated and the upgrade file disappears.

I go the <url>/thebuggenie/public
=> and i cannot login

zegenie

There have been some reports of errors upgrading from versions < 4.1.13. We're investigating how to best solve it, but currently the best upgrade path is from >= 4.1.13 -> 4.3.

tatankat

This error happens when I upgrade directly from 4.1.13 to 4.3
Unknown column 'log27.project_id' in 'field list'

It does not happen when I do it in steps from 4.1.13 -> 4.2 -> 4.3

The direct upgrade works when I move
370 $this->cliEchoUpgradeTable(tables\LogItems::getTable()); 371 tables\LogItems::getTable()->upgrade(upgrade_421\LogItem::getB2DBTable());
in core/modules/installation/Upgrade.php from _upgradeFrom4dot2dot1 to the start of _upgradeFrom4dot1dot13.
Which seems logic as the upgrade from 4.1.13 tries to use log code from 4.3 (when doing $milestone->save()) when the database is still using the 4.1.3 structure.

Afterwards I can't login neither, but for me that is another issue (ldap authentication not refactored?).

David

tatankat
Yes, you're right, the error appears when we attempt to update from 4.1.13 to higher not before.

Successfully upgraded to version 4.1.13
Creating table thebuggenie\core\entities\tables\UserSessions
Updating/fixing status of milestones.


---------------------
An error occured during the upgrade:
Unknown column 'log53.project_id' in 'field list'
---------------------

David

tatankat
Ok i have applied the same correction and i started again from the beginning to be sure that all steps are valid.

And i'm at the same point : the impossible login with admin LOCAL account (not identified into the ldap).

But... i think i understand why : like you (ref. to the auth_ldap module thread), i'm using an ldap and it's a problem when i upgrade versions.

When i install the new version from scratch, TheBugGenie says something like

Please define other users with admin privileges before switching on the ldap module.
So, forcing disabling the ldap module into the setup could enable the connection with the admin (LOCAL) account.

Sim9

I banged my head against this for about eight hours today, coming from 4.1. I had the same milestones upgrade problem that was reported above. Even using the workaround (which might end up causing problems in future if that table isn't upgraded?), I now get:

The module 'agile' is not loaded
An unhandled exception occurred:
/home/bugs/core/framework/Context.php, line 1180:
The module 'agile' is not loaded
Stack trace:

    thebuggenie\core\framework\Context::getModule()
    /home/bugs/core/framework/Context.php, line 714
    thebuggenie\core\framework\Context::loadEventListeners()
    /home/bugs/core/framework/Context.php, line 782
    thebuggenie\core\framework\Context::loadCachedRoutes()
    /home/bugs/core/framework/Context.php, line 589
    thebuggenie\core\framework\Context::initialize()
    /home/bugs/core/framework/Context.php, line 2564
    thebuggenie\core\framework\Context::bootstrap()
    /home/bugs/public/index.php, line 28

I tried intermediate upgrade stopping at 4.2 and managed to get it to install and I could browse around a bit but got a different error when trying to add an issue (I didn't save that one though).

I can't even install a basic fresh copy, as in that route I get a 'Could not load scope' error. =\

Could not load scope. This is usually because the scopes table doesn't have a scope for this hostname
An unhandled exception occurred:
/home/bugs/core/framework/Context.php, line 1939:
Could not load scope. This is usually because the scopes table doesn't have a scope for this hostname
Stack trace:

    thebuggenie\core\framework\Context::setScope()
    /home/bugs/core/framework/Context.php, line 573
    thebuggenie\core\framework\Context::initialize()
    /home/bugs/core/framework/Context.php, line 2564
    thebuggenie\core\framework\Context::bootstrap()
    /home/bugs/public/index.php, line 28

Is this a problem with php 7.3 compatibility?

EDIT: Downgrading to php7.2 fixed the agile module error. So far it seems to be running fine, even though I never ran the milestone upgrade step.

zegenie

Sorry to hear about the struggles. Feel free to join the gitter.im chat if you need help whenever you're stuck.

I'm not aware of any specific 7.3 compatibility issues, but if it works when downgrading and that is the only change it's highly likely that there's an incompatibility problem there.