Doesn't follow Drupal code style really at all

Patch doesn't apply. It should be a cvs diff specific to the module directory, not relative to the directories on your machine.

Patch is still relative to your local filesystem. Please make a cvs diff. http://drupal.org/patch/create

Tests are also missing in patch.

The code you diffed against is not a cvs checkout judging from the block of stuff in .info for version, core, project, and datestamp. Project module adds those lines when it zips up the project and they shouldn't ever be committed back to cvs.

Patch still doesn't pass normal or minor level tests.

• Implementation of hook_x() is a sentence and should end in a period. The same goes for any of the other sentences in the comment block - start with capital, end with period.
• No lines should have trailing space.
• Add // $Id$ to the top of files
• Add @file blocks
• Line 63, case 'validate' isn't indented properly.

Why is there HTML in the submit handler for the settings form? I don't like how that's handled. I don't imagine that the role gets xss scrubbed on insert, so the literal output there seems like an open security door. Try making that just a comma delimited list and use % for the t() instead of ! perhaps?

preg_replace is overkill in hook_init(). Try strtr or str_replace instead.

Why are you accessing $_GET['q'] instead of arg() to read logout?

Should hook_init really be hook_boot?

I'm having trouble with the select distinct from user; thing on install and then keeping an entire copy of the users table. Why can't hook_user load, and update handle null returns so that you don't have to keep a row for every user? If a row exists, then they need their password updated, else, your password is fine.

In hook_user, case update, why not just clean the uid out of the table if the load can handle a missing value?

"Do Stuff" is a totally worthless description for the tests.

I wasn't able to run the tests. It errored out on me, but that might just be my local config gone bad. I only see a test of the form. It is missing some tests still.

• Login as an unprivileged user and assert that you get 403 at the configuration page.
• Assert that the form elements exist before submitting the form.
• Create a second user
• Login as that second user
• Assert that they are redirected to change their password
• Try to set the same password again and assert they can't set the same password
• Set a new password and confirm that it saved
• Logout the second user, and log back in and assert that they were not redirected to change their password.

Might as well roll in #705068: Add a checkbox on user edit (and add) form to force password change on next login and create tests for it. I didn't see that in this patch, either.

I didn't run coder this time, but I don't think if(variable_get('first_time_login_password_change',0)) { spacing would pass either on the if or args. there are similar cases elsewhere

Do Stuff remains, preg_replace remains. Why is the login case commented out in hook_user?

• The DSM for "An administrator has required that you change your password. You must change your password to proceed on the site." needs to be $repeat = FALSE.
• The title and description in hook_menu() don't get t() starting in Drupal 6.
• When I update my own account, the DSM status returns "will be required to change their password the next time they log in." The front of the sentence is cropped.
• When I update my own account, change password on next login is checked by default. That seems wrong. If I leave it checked, after changing my password, I'm still required to change my password again, even though I haven't even logged out. This seems to mean that the check is not based on the login event at all, but just a general force password change or else.
• Updating my own account:
  

  Notice: Undefined index: name in force_password_change_user_submit() (line 187 of /Users/davidnorman/Sites/alisdair/sites/all/modules/force_password_change/force_password_change.module).

Well then I guess we can't play in your fork and we'll just have to move it back to #292166: force password change on next login, where it should have been in the first place.