Thanks a lot for your help.

But There is also another file where exists a email comparaison:

• components/com_users/models/reset.php => function processResetConfirm
• components/com_users/models/remind.php => function processRemindRequest
• ...
  and into other files..... (search for "$db->quoteName('email')")

Could you please add the correction to thoses files @alikon

Can i download the new patch some where?
@alikon
Thanks

you can test with https://docs.joomla.org/Component_Patchtester_for_Testers

Hello,
Thanks for the patchTester,
I tested the patch and it's OK.
Could you merge this branch and build a new patch?

@mdaoudi123 please mark as tested on https://issues.joomla.org/tracker/joomla-cms/24117
this should be carefully tested on mysql side too....and mssql also i'm afraid

Hello,
im going to test it into POSTGRES too,
can you tell me how to mark this post as tested?
Thanks

see https://docs.joomla.org/Testing_Joomla!_patches

I have tested this item ✅ successfully on a7c980e

Tested Successfully on Mysql and Postgres databases.

Thanks

@alikon

Hello,
I have already tested this feature.
Could you please creat a new patch @alikon

Hello,
I have already tested this feature.
Could you please creat a new patch @alikon

one test is not enough, we need at least two, before this pr can be considered by the maintaners

There is an error into the continuous-integration/drone/p

The problem is the phpcs confirmation

@alikon

There is an error into the continuous-integration/drone/p

The problem is the phpcs confirmation

Could do you check whats happening please

@alikon

sorry but really don't know how to fix CS for an inline function

I just wanted to say that the local part of an email is case sensitive, it's ok for me to ignore this because it's common practice to handle email addresses case insensitive.

@HLeithner @alikon
please there is news for this fix?
When this patch will be available?

Please Help

please could you fix the phpcsfixer warning

Any one can help me please

one test is not enough, we need at least two, before this pr can be considered by the maintaners

@mdaoudi123

I tedted the fix. but who can test it another time to deblock the situation
Anyone can test please

Im waiting since 3 months

@richard67 you use Postgresql? Can you please look at this PR?

@franz-wohlkoenig Today I have a full schedule. I will try to find a time slot, but it might be tomorrow until I can do something. I do not really use postgresql, I just have it for testing.

@alikon @franz-wohlkoenig This PR will not work as it is. In the schema update, the index is dropped and then added back with same name. This is valid SQL, but the database schema checker can't handle that due to its bad design, so it will end in a toggle of reported database error "index missing but should exist" and "index existing but it should not". The only thing you can do is to add it back with other name, but the for consistency it might be necessary to change index name for MySQL, too.

thanks @richard67
btw,i don't think we need to do something on mysql side

@alikon Did you test if update notification emails are still working with your change (which I don't fully understand and so I have same question as JM had).

@alikon I've made a PR adding the missing function comment which has to be completed by you, and which fixes a few of the code style issues. But I still do not understand why it needs that call back function stuff. Why don't you just make a local copy of the emails array, lowercase it, and use that for the query? It would not need this inline function and not need this new function and so no need for new function comments and all codestyle could be fine. Can you explain me why it needs to be done in that way with the callback?

ouch i've to admit that i don't remember why i've done that, in that way maybe in that period i worked at the office "complicate simple thing" ? .... hope i'll find free time to rethink soon

@alikon As long as you rethink that, ignore my PR against your branch of this PR. I think about it, too, and maybe come with new PR for your branch.

@alikon I see another problem with the new unique index on postgresql (and later in 4.0-dev where we have MySQL >= 5.7 on MySQL, too, if we add the same index then):

When users do an update of their Joomla and have duplicate lowercase emails in their users table database, like "gaga@blabla.de" and "GaGa@blabla.de", the unique index adding will fail.

It would require to clean existing data by duplicate records. We once had the same problem when we wanted to change collations of com_finder tables in MySQL from general to unicode, because that change would have caused duplicate values, and so we gave that up and remained com_finder tables with general collations.

If you want to keep that new index for performance reasons, then make it non-unique, i.e. just an index.

Or you don't add that new index.

Of course this would not be a problem if we could be sure that the PHP code of the CMS never allowed to add users having same lowercase email address. But I am pretty sure even if that was the case, we could not 100% rely on it over all the history of Joomla version in the update history of a web site.

So I suggest to make the new index non-unique or leave it away.

@alikon P.S. to my previous post: I think @mdaoudi123 did not have that problem during his test because either he did not have duplicate records, or he did not run the schema update sql (which patchtester will also not do) and so he tested only the changes in PHP but not the database change.

@alikon My PR alikon#55 replaces the callback stuff by easier solution and so fixes all cs issues. What remains to be thought about is not to add the new index as unique because it may break update of sites with existing duplicate lowercase email addresses in their data.

@alikon My PR alikon#56 handles the index problems and renames the schema update according to latest releases.

So if you accept my 2 PRs and update yours here with latest staging we can test yours.

thanks @richard67

Drone failure is not related to this PR, is javascript stuff. PHPCS is ok now.

@mdaoudi123 Sorry for the inconvenience and the long waiting time. Could you test this PR again with its latest changes?

@alikon Could you synch this PR with staging by using that button in GitHub at the bottom of your PR?

Unless there are conflicts there is no benefit

Yes but looks less scary for beginner testers.

I have tested this item ✅ successfully on a8c025b

Tested on MySQL and PostgreSQL.

On MySQL it does not break anything.

On PostgreSQL it checks now for present email address in case-insensitive way without touching existing user data.

Tested as follows:

Pre-conditions: In Global configuration, set error reporting to maximum or development and watch the PHP error logs during the tests. Check that there are no errors reported.

1. Without this PR applied, have super admin email address be like e.g. "test@test.local".
2. Create another user with email address be like e.g. "Test@test.local", i.e. same as 1st one but different case.
   Result: User is created.
3. Apply this PR.
4. Go to "Extensions -> Manage -> Database" and fix the database error to apply the schema update sql of this PR.
   Result: Database upt to date.
5. Create another user with email address be like e.g. "tEst@test.local", i.e. same as 1st and 2nd one but different case.
   Result: User is not created because email address already exists.
6. Edit the 2nd user but do not change email address and try to save.
   Result: User can't be saved because email address already exists.
7. Exit user edit without saving.
8. Work a bit in backend with user-related functions like privacy requests or other stuff related to files changed by this PR.
   Result: You can't add new users or change users so more than one user has same email address, case-independent, but the existing 2 users with same case-independent email addresses do not make problems.

@alikon Could you update your testing instructions to what I wrote here above so other users can test more easily?

@alikon why closing this?

@alikon Did you maybe accidently hit the wrong button, close instead of rebase?

I have tested this item ✅ successfully on 27d3519

@mdaoudi123 Sorry for the inconvenience.

Could you test this PR again with its latest changes?

And then mark your test result at the issue tracker here https://issues.joomla.org/tracker/joomla-cms/24117, using the "Test this" button at the top left corner? Then just select the appropriate result and submitt.

I have tested this item ✅ successfully on 27d3519

I have tested this item ✅ successfully on 27d3519

RTC.

Thank's a lot.

@alikon This correction will be available into the new joomla release?.

regards

it's up to the maintainers/release lead to decide if and when

Can you please rename the sql file to 3.9.15 then I will merge this.

renamed

I'm not the biggest fan this PR but think it solves more problems then it creates.

Thanks