don't we need to add that to the update scripts too?

yes, i'll add the update script part too when @home ;)

?

I have tested this item ✅ successfully on a934f41

@alikon can you give Test Instructions for non-Technicals or is this PR for Technicals?

from phpmyadmin look at #__user_keys indexes you'll see series_2, series_3
apply the patch and reinstall
from phpmyadmin the #__user_keys table have only one index on the field series

thanks @alikon, will look into it.

how to get series_2? Field series in Table #__user_keys is empty.

System information

3.7.3-dev (latest nightly build)
Multilanguage Site
macOS Sierra, 10.12.5
Firefox 53 (64-bit)

MAMP 4.1.1

• PHP 7.0.15
• MySQLi 5.6.35

how to get series_2? Field series in Table #__user_keys is empty.

It's not a field, it's the index of the "series" field.
You can populate the field by logging in while having the "Remember Me" checkbox enabled.

Thanks @Bakual. With and -out PR and relogin got:

@franz-wohlkoenig Aplly PR then run database fix and see in phpmyadmin that you don't have series_2 and series_3 indexes.

I have tested this item ✅ successfully on 26b65b9

@waader can you please retest?

I made a mistake when I tested. This is still a problem with installation on mssql.

Can you make the sqlrv changes to my branch wich is public, and i
currently don't have a. sqlsrv instance to test, thanks ;)

On 29 Jun 2017 10:39 pm, "Tomasz Narloch" notifications@github.com wrote:

@csthomas requested changes on this pull request.

In installation/sql/sqlazure/joomla.sql
#15509 (comment):

CREATE NONCLUSTERED INDEX "user_id" ON "#__user_keys"
(
"user_id" ASC
-)WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF,
DROP_EXISTING = OFF, ONLINE = OFF);
+)WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF,
DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY];

Please revert above line.

In installation/sql/sqlazure/joomla.sql
#15509 (comment):

@@ -2906,21 +2906,12 @@ CREATE TABLE "#__user_keys" (
CONSTRAINT "#__user_keys$series" UNIQUE NONCLUSTERED
(
"series" ASC
-)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY
= OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY],

• CONSTRAINT "#__user_keys$series_2" UNIQUE NONCLUSTERED
  -(
• "series" ASC
  -)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY
  = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY],
• CONSTRAINT "#__user_keys$series_3" UNIQUE NONCLUSTERED
  -(
• "series" ASC
  -)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY
  = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
  -) ON [PRIMARY];
  +)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY
  = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY];

Add to this line:
) ON [PRIMARY]; and remove ; from above

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#15509 (review),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AALFsch2KaLq447xDQrKtLxtN2RuWWs8ks5sJAuagaJpZM4NGUK9
.

I have tested this item ✅ successfully on 9255ee3

Is there any chance it will be merged?
It was tested on 3.7.3.
It's trivial but stuck for a long time.

it seems that you still request a change

and it still have only 1 test

Human Test Results: 1 Successful 0 Failed.

so don't get the RTC label

I did not realize that I should click to approve this, after making changes.

I have tested this item ✅ successfully on 9255ee3

Tested with MySQL

can we have an RTC status?
and 3.8.4 milestone ?

Ready to Commit after two successful tests.

@brianteeman can please you set the Milestone?

i will leave it to @mbabker to set the milestone as i dont understand it enough to know if it is a bug fix or not

@joomla/cms-maintainers any chance for 3.8.4 ?

From everything I can tell it's just human error it was triplicated unless someone can find something in https://developer.joomla.org/joomlacode-archive/issue-31561.html #2101 or #1745 explaining the triplication (note it's not in the old security tracker either where this was discussed before becoming a public patch).

really curious how the same (triplicated) index can be tied with security ?