Moodle

Lang file for auth specifies incorrect file path in lang/en_utf8/auth.php

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.6.3, 1.6.4, 1.7
  • Fix Version/s: 1.8
  • Component/s: Language
  • Labels:
    None
  • Affected Branches:
    MOODLE_16_STABLE, MOODLE_17_STABLE
  • Fixed Branches:
    MOODLE_18_STABLE

Description

The language file lang/en_utf8/auth.php specifies in the $auth_dbpasstype variable the path to a file called auth/db/cron.php (which doesn't exist), when it should specify a file called auth/db/auth_db_sync_users.php.

This should be checked in all the language files (I have only checked the 'master' en_utf8 lang files).

Saludos. Iñaki.

Issue Links

This issue will be resolved by:
MDL-8542 External db auth cleanup - META Blocker Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Petr Škoda (skodak) added a comment -

fixed in cvs (for all langs), thanks for the report!

Show
Petr Škoda (skodak) added a comment - fixed in cvs (for all langs), thanks for the report!
Hide
Permalink
Martín Langhoff added a comment -

Hang on in there. Iñaki's report is wrong – this depends on bog standard admin/cron.php

Show
Martín Langhoff added a comment - Hang on in there. Iñaki's report is wrong – this depends on bog standard admin/cron.php
Hide
Permalink
Martín Langhoff added a comment -

This should actually mention admin/cron.php - the standard Moodle cron rather than auth_xx_sync_users.php

Show
Martín Langhoff added a comment - This should actually mention admin/cron.php - the standard Moodle cron rather than auth_xx_sync_users.php
Hide
Permalink
Petr Škoda (skodak) added a comment -

If I understand it correctly the auth/db/auth_db_sync_users.php must be run from unix cron job and moodle admin/cron.php must be executed in order to get temporary password by email.
I have changed it in cvs to admin/cron.php in cvs, because I agree that is makes sense there.

We might rephrase it in English 1.7 lang pack to mention that the execution of auth/db/auth_db_sync_users.php from unix cron is also needed, what do you think Iñaki?

Show
Petr Škoda (skodak) added a comment - If I understand it correctly the auth/db/auth_db_sync_users.php must be run from unix cron job and moodle admin/cron.php must be executed in order to get temporary password by email. I have changed it in cvs to admin/cron.php in cvs, because I agree that is makes sense there. We might rephrase it in English 1.7 lang pack to mention that the execution of auth/db/auth_db_sync_users.php from unix cron is also needed, what do you think Iñaki?
Hide
Permalink
Eloy Lafuente (stronk7) added a comment -

Any comment here...? :-P

Show
Eloy Lafuente (stronk7) added a comment - Any comment here...? :-P
Hide
Permalink
Iñaki Arenaza added a comment -

Ooops! I forgot about this.

Martin L. is undoubtly more expert than me in this area, but when I read the code in auth/db/lib.php to file this bug report, running auth/db/auth_db_sync_users.php was really needed for this to work.

In function auth_sync_users(), we check if $auth_dbpasstype is 'internal' or not, and then set the user preferences to force a password change and to create a new password. I guess this is what admin/cron.php checks later to send the email to the users, but unless we run auth/db/auth_db_sync_users.php in the first place, admin/cron.php will never see those preferences (and specifically the need to create a new password) and send those emails.

Of course, I could be wrong

Saludos. Iñaki.

Show
Iñaki Arenaza added a comment - Ooops! I forgot about this. Martin L. is undoubtly more expert than me in this area, but when I read the code in auth/db/lib.php to file this bug report, running auth/db/auth_db_sync_users.php was really needed for this to work. In function auth_sync_users(), we check if $auth_dbpasstype is 'internal' or not, and then set the user preferences to force a password change and to create a new password. I guess this is what admin/cron.php checks later to send the email to the users, but unless we run auth/db/auth_db_sync_users.php in the first place, admin/cron.php will never see those preferences (and specifically the need to create a new password) and send those emails. Of course, I could be wrong Saludos. Iñaki.
Hide
Permalink
Martín Langhoff added a comment -

Ok - Skodak did point out that for things to work in this scenario you need to run both auth/db/auth_db_sync_users.php and then admin/cron.php so my initial comment was wrong as well

[Which means that I should enter a bug against myself to get all the auth_xx_sync and enroll_zz_sync to be complemented by an option to run from admin/cron.php.]

Show
Martín Langhoff added a comment - Ok - Skodak did point out that for things to work in this scenario you need to run both auth/db/auth_db_sync_users.php and then admin/cron.php so my initial comment was wrong as well [Which means that I should enter a bug against myself to get all the auth_xx_sync and enroll_zz_sync to be complemented by an option to run from admin/cron.php.]
Hide
Permalink
Petr Škoda (skodak) added a comment -

fixed in cvs, thanks for the report

Show
Petr Škoda (skodak) added a comment - fixed in cvs, thanks for the report

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Moodle. Try JIRA - bug tracking software for your team.