Newman wrote:

I am pretty sure most of the developers here are fluent in english

It depends on what you call 'fluent'

well for me, im 100% english but some french here have way better english then me im just lazy @ typing :d

• Announcements -- public

• Admin Talk -- visible, writable to admins

• Friends Talk -- visible and writable to my friends, but not normal users

• Offtopic -- public

Let's assume a friend of mine is an admin. He'll need a speciel group to access both, Friends Talk and Admin Talk. Admins need an extra group, because admins (in sense of team members, moderators, etc.) don't necessarily need to view my personal friends forum. Also, some of my Friends need to see Friends Talk, but not Admin Talk. Therefore I need another group. (E.g. these groups: Friends, Admins, FriendAdmins, RegularUsers, and perhaps an "AdminViewOnly" group if I want someone to see what we write.)

This is annoying and it would be much easier if you could create different groups and assign an user to more than just one group.

Maybe we will see something like this with the 2.0 : http://stats.punres.org/list.php (the devs talk about it some months ago). But it'll always be just a list, we don't have to decide which one is useful and which is not. It all depend of your personals interests...

what kind of notifications would you want to send? wouldnt this cost some money to send the text messages in the first place?

All the Email notifications and also phone registration!
It may promote forum's and can get a lot of member's easily.

You guys are right, atm only mcrypt and sessions use /dev/urandom; it probably was suhosin what added this feature to other functions. Trying to read from /dev/urandom directly might be problematic; think about open_basedir. Some hosts might not allow you to alter it to be able to read anything from /dev. Therefor I suggest using mcrypt_create_iv here and fall back to the built-in rand functions. Apparently we don't need a real random number for the salt but just make sure it's most likely different for every user.

For backwards-compatibility: maybe we can make it configurable? So people who for some reasons have to keep sha1 can still update.

OK, so that F algo is just used when crypt is not available? Should work for me. My motivation here was that I indeed have to integrate with third party apps that only support the standard crypt function (MD5, Blowfish, SHA-256 and SHA-512). Maybe we can add SHA-512 though as not all systems seem to support Blowfish. From the crypt manual:

       The glibc2 version of this function supports additional encryption algorithms.

       If salt is a character string starting with the characters "$id$" followed by a string terminated by "$":

              $id$salt$encrypted

       then instead of using the DES machine, id identifies the encryption method used and this then determines how the rest of the password string is  interpreted.   The  following
       values of id are supported:

              ID  | Method
              ─────────────────────────────────────────────────────────

              1   | MD5
              2a  | Blowfish (not in mainline glibc; added in some
                  | Linux distributions)
              5   | SHA-256 (since glibc 2.7)
              6   | SHA-512 (since glibc 2.7)

       So $5$salt$encrypted is an SHA-256 encoded password and $6$salt$encrypted is an SHA-512 encoded one.

       "salt"  stands  for the up to 16 characters following "$id$" in the salt.  The encrypted part of the password string is the actual computed password.  The size of this string
       is fixed:

       MD5     | 22 characters
       SHA-256 | 43 characters
       SHA-512 | 86 characters

       The characters in "salt" and "encrypted" are drawn from the set [a–zA–Z0–9./].  In the MD5 and SHA implementations the entire key is significant (instead of only the first  8
       bytes in DES).

Not sure about PHP 5.2 or even 4 though. We could indeed fallback to a less secure function here.

Wan wrote:

As we're now in an olympic year :
"Faster, lighter, smarter..."

Like this one !!

+1

example,if you want to reply all members reply in topic just click the MQ no need to copy and paste..

this is easy way to reply faster to all members reply in topic..

On - if you want to use PM in forum

Off - If you don't Want To Use PM in forum

What Did You Think Guys..

Because Email Messaging is For Professional Only.. how about the others don't have a knowledge in computer.. don't know how to verify the email add, don't know how to send message using email,.

We actually use StopForumSpam here. For 2.0 we might well consider having it as an official (and potentially even installed by default) extension.

This is great news!!!

Is it possible that you only tried downloading from the mod page? You need to click on "Go to release" (at the side of the download button) to see the other download options. I guess we should make that clearer...

Gil wrote:

A "manual" (and usable) alternative can be:

• a new admin function "manage unverified users" (a new area in the moderation/users menu for example, after IP search area)

• with a parameter = number of days "older than xxx will be deleted" (default 7 or 15 or 30).

• and a button "delete all" ...

There's a plugin to do that

http://fluxbb.org/resources/mods/user-management/

Maybe. I know how to use phpmyadmin too. But when something is not only useful, but essential, my opinion is that there is a need for a core function.
And a function is essential when something *must*  be done, and there still is no internal (and always usable) function to do it...
Only my opinion

Help yourself

Kind of forgot about this.

It is a good idea, though, so if anybody come up with a quick and detailed spec, that might improve your chances of me / someone else doing it.