Competencies do not appear to work correctly.

When marking attendance for a classroom course, the competency appears to record the date that the attended was checked off, and not for the date the course took place. For example, if the course took place on a Friday, and the user manager then marked the course as having been attended on when they return to the office on Monday, the course competency will be marked at 3 days over the date the course expires.

Therefore the competency needs to take its expiry date from the date the course ran, not the entry date of data. This is a fundamental flaw when using classroom courses and competencies, and therefore makes the system unusable for tracking competencies.

Will this be fixed in future? It's a major feature that doesn't seem to work correctly.

Looks like the ?r=alms/classroom/presence controller is not passing the correct date back to the system when clicking the 'Save Changes' button. I'll try to pick this apart and update the code if it hasn't been done already?

public function setDateFinished($id_date, $id_user)
{
$query = "UPDATE ".$this->user_date_table
." SET date_complete = '".date('Y-m-d H:i:s')."'"
." WHERE id_date = ".$id_date
." AND id_user = ".$id_user;

return sql_query($query);
}



Really?

This could be a solution:
Btw, I'm glad the code makes you so hilarious, but your comment can be understood as disrespectful.
Hope my solution is the one that you were searching for. I'm sure you would have found that (or maybe better) in a couple of minutes.

It wasn't meant as disrespectful, it was humour as a programmer looking at something and finding it amusing. Lighten up and stop taking everything so seriously.

I'm guessing the code I highlighted was built around the registration of an eLearning course completion, triggered by the event. Therefore, inserting today's date would be adequate for this, but not for anything else. The person who wrote it would have known it worked for the purpose it was intended, but then someone later came along and added functionality to the system that the code didn't cope with. This is English irony, which is amusing.

I stumbled across some weird 'old' code to strip a date string down to days and months etc last night, when using the PHP function Date() would have done the job in 1 line of code. I also laughed at that.

As I mentioned, lighten up, we're all working towards the same goal, and as Max pointed out, the code has evolved over time. Although you can quite clearly see how it has evolved when looking through the code base and seeing varying styles, and even structure.

I'll keep updating my code base and share back any improvements with the community.

Thank you would have been enough.

alfa24 wrote: ↑Mon Feb 08, 2021 12:13 pm Thank you would have been enough.

Thank you

Is there a reason that the MySQL date field is filled with a zero date from the code, when setting it to NULL would be more appropriate? Or is this historical code?

It seems to happen in lots of sections of code, for not apparent reason, unless a NULL value for a date would cause a code error elsewhere, which could be handled by an error handler.

Maybe the filed in the DB has been set with a 0000:00:00 default value instead of NULL.

alfa24 wrote: ↑Mon Feb 08, 2021 12:43 pm Maybe the filed in the DB has been set with a 0000:00:00 default value instead of NULL.

Thanks alfa24. There are specific pieces of code that send 0000-00-00 to the database. Not sure why they do that when they could send NULL. I'll take a look later and update.