Can't update version to a new course that has been created

[b22chran]

When a course is created from the course overview and trying to access it, it wants to add a new version to the course. When trying to add a version it doesn't seems to save it to the database. Locate where the call to the database is performed and fix that it saves the version to the table vers in the database.

[a22chrfa]

Log:

Creating a new version on a newly created course is indeed not working, while the very same function is working on an existing course with existing versions. Why is there a difference if the same function is being used? They might not be sending the exact same data though. Check by manually editing data in the object being sent to the database.

Furthermore, the function seems to to have more issues than originally described. Even when successfully creating a new version, the dates set isn't saved in the database. Also, if the setting the new version to default, that isn't saved either. It appears this can only be done when editing an existing version. Check this after figuring out issue in above paragraph.

createversion() and updateVersion() are located in sectioned.js, they both make calls to AJAXService() defined in dugga.js.

[a22chrfa]

Log update:

They didn't didnt send the same data, but this wasn't the issue.

The two scenarios used is:

1. Create a new version on an existing course with existing versions
2. Create a new version on an existing course without existing versions

What has been confirmed so far is that both scenarios use the same function (createVersion) in sectioned.js. They now also send the exact same data when calling AJAXService(). They still produce different results; scenario 1 gets created in the database, scenario 2 doesn't.

By tracing the callstack and logging, it was confirmed that the AJAXService() ultimately calls "createCourseVersion_ms.php". From here the variables containing the values can't be logged into the browser, as these functions are executed backend. The input sent to this php-file has been confirmed to be the same, and therefore we should be able to trust that the variables storing the input data in this file should be both the same, and correct, in both scenarios. The variables in here were manipulated to manually give the same exact values in both cases, yet they still produce different results. Manipulating the code further is pointless.

When looking for logs I was able to find in the access logs in xampp that in both scenarios, I got a 200-response from the database (which simply means, "ok"). This should mean that the calls to the database should have been successful. I couldn't find any other logs of value to this issue though.

By creating a general_log in the mysql database the transactions for lenasys could now be logged, which revealed something of interest.

Working scenario:

• `('2024-04-15 13:50:16.334682', 'a22chrfa[a22chrfa] @ localhost [::1]', 96, 1, 'Query', 'INSERT INTO vers(cid,coursecode,vers,versname,coursename,coursenamealt,startdate,enddate,motd) values(\'4\',\'IT301G\',\'979791\',\'HT25\',\'Software Engineering\',\'UNK\',NULL,NULL,\'yeeeeeeee\')'),
• ('2024-04-15 13:50:16.337482', 'a22chrfa[a22chrfa] @ localhost [::1]', 96, 1, 'Quit', ''),`

Non-working scenario:

• `('2024-04-15 13:46:43.137859', 'a22chrfa[a22chrfa] @ localhost [::1]', 65, 1, 'Query', 'INSERT INTO vers(cid,coursecode,vers,versname,coursename,coursenamealt,startdate,enddate,motd) values(\'4\',\'IT301G\',\'696969\',\'HT25\',\'Software Engineering\',\'UNK\',\'2024-04-01\',\'2024-04-30\',\'erthgehg\')'),
• ('2024-04-15 13:46:43.139908', 'a22chrfa[a22chrfa] @ localhost [::1]', 65, 1, 'Query', 'SELECT * from quiz WHERE cid=\'4\' AND vers = \'111111\''),
• ('2024-04-15 13:46:43.140063', 'a22chrfa[a22chrfa] @ localhost [::1]', 65, 1, 'Query', 'SELECT * from codeexample WHERE cid=\'4\' AND cversion = \'111111\''),
• ('2024-04-15 13:46:43.140198', 'a22chrfa[a22chrfa] @ localhost [::1]', 65, 1, 'Query', 'SELECT * from listentries WHERE vers = \'111111\''),
• ('2024-04-15 13:46:43.140400', 'a22chrfa[a22chrfa] @ localhost [::1]', 65, 1, 'Query', 'UPDATE course SET activeversion=\'696969\' WHERE cid=\'4\''),
• ('2024-04-15 13:46:43.141094', 'a22chrfa[a22chrfa] @ localhost [::1]', 65, 1, 'Query', 'ROLLBACK'),`

This seems to be consistent with every try for the different scenarios.

A few things to point out:

• The working scenario has null dates (even when set in form). The non-working scenario has actual dates. This is an additional issue.
• The non-working scenario is obviously running more code, ending with a rollback instead of a quit. Could this be due to the dates?
• The variables was manually manipulated right before the call to the database, yet they're sending different data. This suggests that some sequencing in the code with the variables (they're global) is not working properly. This makes the issue a bit more complex since the code surrounding this is, to put it lightly, a mess. The code has obviously degraded over time.
• This explains the 200-answers. We actually successfully make our request of inserts in both cases, but something in our code is triggering a rollback.

More logging will be done. For now I'll jump ahead and say that I've managed to make inserts into the database by making sure that the excess queries from the non-working scenario doesnt run. But for some reason the website can't seem to fetch and present these from the database, even though they look exactly the same. So there's a new issue. Apart from this I've noticed a ton of issues surrounding this that might need to be fixed either in this issue, or another, they will be listed at a later stage.

[a22chrfa]

Log update:

After further investigating the excess functions that was being triggered I found out that part of the issue was apparently actually solved during the first few code fixes. But this was masked due to the issue (later revealed) being a two part issue.

1. Making inserts into the database doesn't work.
2. Even if an insert is made, the page doesn't actually fetch and display it.

Inserts weren't working due to an if statement in the "createVersion" function. The if statement checks the variable "param.copycourse". If set to "None", the correct function is being executed via AJAXService. However, in the case where a course has no versions, the form doesn't allow the user to select "None" and the value therefore remains undefined or empty, which instead triggers the "copy version" function via AJAXService.

One of the first fixes was making sure that the forms send the same data, which (at least for this variable) was working. So when trying this in the first few tests the inserts to the database was actually made, but they didn't display the version on the website. My wrongful assumption was that if it didn't turn up on the website, then the insert must not have been made. The fix was essentially masked by another error.

So making the insert is now has a known fix and it looks as expected in the database, but another issue remains. It doesn't show on the website.