I'm having quite a few issues trying to upgrade our v1.12.2 instance to 1.18.1

I tried doing in-place upgrades and ended up having a lot of problems that we tried to debug without any luck. I ended up reverting to the snapshot before the upgrade to get the system back up and running.

As part of our conversation about the first set of problems, we decided that it might be better to build a new server and just import the old db. I did that, built a Ubuntu 24.04 server with Apache, mysql, and PHP8.1. I downloaded and got 1.18.1 setup and functioning on this new server. On the old server, I did a mysqldump out to a sql file for the entire db. Copied that file over to the new server and imported the sql file into the db on the new server. I also changed the following values in the ost-config.php file to match the db that I imported (SECRET_SALT, ADMIN_EMAIL, DBNAME, DBUSER, DBPASS).

When I launch the site I'm having many issues. So far, this is what I have found. I'm assuming as I go along I will find more issues.

• The login for agents just spins endlessly after typing in the username/password. If I refresh the page it will take me to the agent page. I have not tried the login for the user side. (There were similar login issues when we did the upgrade the first time.)
• The custom logo and background are broken. I assumed that was because the image files did not come over with the import. I then tried to upload the logo again and still have a broken image.
• We use the ldap plugin and ldap for all of our normal user and agent logins. I verified the settings came across in the import and clicked save to make sure it was all happy with the ldap php module. I got the green bar to say successful. ldap is still not working for the agent login. (This was one of the big problems we had before because the user and staff tables did not update correctly with the update script.)
• Most of the tickets are not showing in the agent page. The ticket table shows over 24000 rows but I can only see nine tickets total.

Can you see anything I missed or suggestions on tackling these anything else that may come up?

KevinTheJedi

Thanks for the reply. I'll answer each one here.

1. I did download the plugin for 1.18.x but didn't have it in the folder when I did the db import and upgrade. I'll wipe everything out and try it again with that plugin in the folder.
2. I do not use an attachment plugin. It is set to save attachments in the db with a 2Mb limit.
3. See #1
4. You hit that one on the head, it was totally a department access setting. In changing the setting I did notice that there is an inconsistancy with the departments. The local user that I'm logging in with had the primary department set to and active but private (internal) department. There was a red error on the page saying the primary department needs to be active. I did confirm it is set to active but it still does not show up in the dropdown list for primary department. It does however show for the extended access.

I thought the same thing about the config file but looking at it using diff there were so many other things in the new version I was afraid because I'm so far behind that something wouldn't work right if I kept the old file.

KevinTheJedi

2. I even tried loading up in an incognito window just to make sure I wasn't hitting a cache kinda issue. ¯\(ツ)/¯
   I'll take a look in the db after my next attempt and see what I can find.

I do have a couple tweaks I have done to a couple php files but they are really basic things like changing wording of text.

KevinTheJedi

I dropped the db and recreated it. Then imported the old db. Everything looks good so far.

Went to run the upgrade script and it is asking me to login (just same as last time). When I enter the local user credentials, it sits and spins. A page refresh just returns to the login. I re-enter the credentials and it spins again. I go to the address bar and remove the login.php so it is just tld/scp and then it loads the upgrade page.

Good news it appears ldap is working for staff, but bad news it's not working for users. Inspecting the db tables, it looks like the update script updated the backend field for _staff table but did not update it for the _user table. The _staff table backend field updated to ldap.p1i2 but the _user table stayed ldap.client so when I manually update a user to ldap.client.p1i2 that user can login. Interesting the user side logs right in with no issues.

I checked the _file table and found both the B and L files. Both files have data in the _file_chunk table. From the web interface I changed back to the stock logo and backdrop. I then deleted the custom entries. Verified the stock images are loading correctly. Uploaded a new logo and verified it saved to both tables. The logo shows as a broken image in the web interface. Changed logo for both Client and Staff to the custom logo and saved changes. Then tried loading the site in an incognito window, logo is broken.

KevinTheJedi

Okey dokey, looks like the image issue was self inflicted. I reverted all my php changes and now it's working correctly. I'll have to go through my code and see what/where it breaking.

Any thoughts on why the _user_account table didn't update the backend correctly with the update?

KevinTheJedi

I did get everything working. Turned out I had a typo in how I added a comment to a php file and that was breaking everything

Still have the issue of the _user_account table not having the backend column updated by the update script.

Found one more thing. When viewing a ticket on the agent side that was brought over with the db import the 'Issue Description' field seems to be stipping off the "<br />" tags that are saved in the db.

Here is what the value is in the db

Hi Dave, <br />Please replicate the following tables from dataLink.<br /><br />Server: srv90037<br />Database: lccIRDataLinkDataWarehouse<br /><br />WAREHOUSE_FINAID.FA_AWARD<br />WAREHOUSE_FINAID.FA_AWARD_SNAPSHOT<br />WAREHOUSE_FINAID.FA_STUDENT<br />WAREHOUSE_FINAID.FA_STUDENT_AWARD<br />WAREHOUSE_FINAID.FA_STUDENT_AWARD_SNAPSHOT<br />WAREHOUSE_FINAID.FA_STUDENT_AWD_CANCELED<br />WAREHOUSE_FINAID.FA_STUDENT_NEED<br /><br /><br />I just created a target file using the lccFileRowsTurnOnOff tool. The tables that need to be updated were all found in the tool's checkboxes.<br /><br />Thanks! <br />

And here is how it's being displayed in the browser

Hi Dave, Please replicate the following tables from dataLink.Server: srv90037Database: lccIRDataLinkDataWarehouseWAREHOUSE_FINAID.FA_AWARDWAREHOUSE_FINAID.FA_AWARD_SNAPSHOTWAREHOUSE_FINAID.FA_STUDENTWAREHOUSE_FINAID.FA_STUDENT_AWARDWAREHOUSE_FINAID.FA_STUDENT_AWARD_SNAPSHOTWAREHOUSE_FINAID.FA_STUDENT_AWD_CANCELEDWAREHOUSE_FINAID.FA_STUDENT_NEEDI just created a target file using the lccFileRowsTurnOnOff tool. The tables that need to be updated were all found in the tool's checkboxes.Thanks!

Interestingly when I click to edit the ticket (as an agent), then everything displays correctly.

KevinTheJedi

Sure no problem.

Here is a screenshot from the 1.12.2 system

Here is a screenshot from the 1.18.1 system (/scp/tickets.php?id=24766)

Here is a screenshot from the edit ticket page on the 1.18.1 system (/scp/tickets.php?id=24766&a=edit)

KevinTheJedi

That is actually a huge problem for us. Seems like turning off/on the display of HTML should be up to us. Do you have any recommendations for how to fix this? I cannot go live with the upgrade until that is fixed (it's that big of an issue).

KevinTheJedi

OK, thank you. Couple more thoughts and questions about this.

When did this get changed? From your stand point, would there be any issues with grabbing the code from the 1.12.1 system and using it in the 1.18.1? I mean just the part for displaying this with HTML.

I'm also a bit baffled as to why we have a wysiwyg type box on the user side for them to type in all kinds of fancy HTML kinda stuff and then completely strip it out when the agent views the ticket. Just trying to understand the bigger picture as to why this change was made.

BTW, huge thank you for all your time in the forum here and all your work on this!

KevinTheJedi

Thank you for all that help. Given I'm on a dev server right now I was able to test out and idea that seems to be working and wanted to let you know what I did.

In the file include/staff/ticket-view.inc.php I found where the Laravel function Format::striptags() is being used to strip out all the HTML. Since this function does not have any built-in control options I switched over to using the PHP funtion strip_tags(). Here is the snippet of what I did that is working for me.

foreach ($displayed as $a) {
    $id =  $a->getLocal('id');
    $label = $a->getLocal('label');
    $field = $a->getField();
    $config = $field->getConfiguration();
    $allowedTags = '<p>,<br>';
    $html = isset($config['html']) ? $config['html'] : false;
/*  $v = $html ? Format::striptags($a->display()) : $a->display(); */
    $v = $html ? strip_tags($a->display(), $allowedTags) : $a->display();
    $class = (Format::striptags($v)) ? '' : 'class="faded"';
    $clean = (strip_tags($v, $allowedTags))
        ? ($html ? strip_tags($v, $allowedTags) : $v)
        : '&mdash;' . __('Empty') .  '&mdash;';
/*  $clean = (Format::striptags($v))
        ? ($html ? Format::striptags($v) : $v)
        : '&mdash;' . __('Empty') .  '&mdash;'; */