1. 25 Apr, 2002 1 commit
  2. 24 Apr, 2002 1 commit
  3. 02 Apr, 2002 2 commits
  4. 05 Mar, 2002 1 commit
  5. 01 Mar, 2002 2 commits
  6. 28 Feb, 2002 1 commit
  7. 04 Feb, 2002 1 commit
  8. 20 Jan, 2002 1 commit
  9. 08 Nov, 2001 1 commit
  10. 19 Oct, 2001 1 commit
  11. 10 Oct, 2001 1 commit
  12. 24 Sep, 2001 1 commit
  13. 11 Jul, 2001 1 commit
    • justdave%syndicomm.com's avatar
      Fix for bug 77473, bug 74032, and bug 85472: Passwords are no longer stored in… · 02226521
      justdave%syndicomm.com authored
      Fix for bug 77473, bug 74032, and bug 85472: Passwords are no longer stored in plaintext in the database.  Passwords are no longer encrypted with MySQL's ENCRYPT() function (because it doesn't work on some installs), but with Perl's crypt() function.  The crypt-related routines now properly deal with salts so that they work on systems that use methods other than UNIX crypt to crypt the passwords (such as MD5).  Checksetup.pl will walk through your database and re-crypt everyone's passwords based on the plaintext password entry, then drop the plaintext password column.  As a consequence of no longer having a plaintext password, it is no longer possible to email someone their password, so the login screen has been changed to request a password reset instead.  The user is emailed a temporary identifying token, with a link back to Bugzilla.  They click on the link or paste it into their browser and Bugzilla allows them to change their password.
      Patch by Myk Melez <myk@mozilla.org>
      r= justdave@syndicomm.com, jake@acutex.net
      02226521
  14. 20 Jun, 2001 1 commit
    • justdave%syndicomm.com's avatar
      Fix for bug 45918: the old password field on the userprefs page is now used to… · 1438d64a
      justdave%syndicomm.com authored
      Fix for bug 45918: the old password field on the userprefs page is now used to log you back in if you try to change your password with cookies turned off, which avoids the confusing login screen after entering your new password in which you used to have to enter your old password one more time in order to let it set your new password (yes, it used to be as confusing as that just sounded :)
      r= tara@tequilarista.org
      1438d64a
  15. 06 Jun, 2001 1 commit
  16. 24 May, 2001 1 commit
  17. 17 Apr, 2001 1 commit
  18. 08 Apr, 2001 1 commit
  19. 07 Apr, 2001 1 commit
  20. 09 Mar, 2001 1 commit
  21. 15 Feb, 2001 1 commit
  22. 25 Jan, 2001 1 commit
  23. 23 Dec, 2000 1 commit
    • dmose%mozilla.org's avatar
      changes from jake@acutex.net to make it possible to toggle the default value of… · be610ad9
      dmose%mozilla.org authored
      changes from jake@acutex.net to make it possible to toggle the default value of newemailtech for new profiles, this is set by default to be turned on (the old default was off) ; r=dmose@mozilla.org.  changes from me to make newemailtech the default in all new installations, and update the verbiage in various spots to make it clear that newemailtech is now considered the one true way and the old tech will be going away.  r=endico@mozilla.org,cyeh@bluemartini.com
      be610ad9
  24. 13 Sep, 2000 1 commit
  25. 24 Jun, 2000 1 commit
  26. 22 Apr, 2000 1 commit
  27. 29 Mar, 2000 1 commit
  28. 10 Mar, 2000 1 commit
  29. 17 Feb, 2000 1 commit
    • terry%mozilla.org's avatar
      Major spankage. Added a new state, UNCONFIRMED. Added new groups, · e9a32920
      terry%mozilla.org authored
      "editbugs" and "canconfirm".  People without these states are now much
      more limited in what they can do.
      
      For backwards compatability, by default all users will have the
      editbugs and canconfirm bits on them.  Installing this changes as is
      should only have one major visible effect -- an UNCONFIRMED state
      will appear in the query page.  But no bugs will become in that state,
      until you tweak some of the new voting-related parameters you'll find
      when editing products.
      e9a32920
  30. 05 Feb, 2000 1 commit
  31. 25 Jan, 2000 2 commits