Project

General

Profile

Actions

Bug #5360

closed

course administration

Added by Parcifal Aertssen about 11 years ago. Updated about 11 years ago.

Status:
Bug resolved
Priority:
High
Assignee:
-
Start date:
27/08/2012
Due date:
% Done:

0%

Estimated time:
Complexity:
Normal

Description

The titular of the course is incorrect in course administration. If you then update the form, you are no longer the titular, but the first user (John Doe) is then the titular

Actions #1

Updated by Parcifal Aertssen about 11 years ago

this when using course types

Actions #2

Updated by Sven Vanpoucke about 11 years ago

  • Status changed from New to Needs more info

The list of course administrators is the list of everyone that is added to you chamilo installation with the status teacher. The course titular is selected from the settings, if the settings are not correctly created during course creating (due to faulty batch scripts) then the course titular is not correctly set in the course settings and when you edit the form he selects the first available teacher from the list.

Updating your batch scripts when creating courses should fix this issue.

Actions #3

Updated by Parcifal Aertssen about 11 years ago

no, the course titular is correctly set. You even see the teacher in the courses overview, you see the visual code, the correct name of the teacher and the language, but if that teacher goes to course settings, the titular of the course type is shown.

Actions #4

Updated by Sven Vanpoucke about 11 years ago

That is because the titular, language and category is duplicated in the course table for performance reasons. If it's also correctly set in the settings then the form will be ok.

Actions #5

Updated by Parcifal Aertssen about 11 years ago

OK, thanks, this helped me.

But why do you keep the data in 2 tables, you only need the one in the course table? Especially if you keep them sync anyway... this makes updates more complex...

Actions #6

Updated by Sven Vanpoucke about 11 years ago

  • Status changed from Needs more info to Bug resolved

The data is currently in two tables because we have a generic settings system which can deploy settings from course types to courses very easily. However, this resulted in having many issues when showing a simple course list because settings are now in 4 tables. To avoid having to make complex joins it was better to denormalize the database and duplicate the data that was necessary to show the course list in the course table.

Actions

Also available in: Atom PDF