Symphony.

Symphony always prompts an error message that passwords didn't match when changing anything in a profile but the password. Symphony shouldn't care about the password when the user didn't enter a new one.

Is your browser auto-filling the fields?

No, it's not (latest Safari on Mac OS X). But it's possible to save an author if I click Change password first. Strange ...

I can't reproduce this.

1. Open up my profile
2. Click 'Change Password'
3. Click 'Save Changes'
4. Page saves and reloads successfully

I might add clearing the autopopulated 'Old Password' field makes no difference.

What extensions do you have installed?

I can't confirm this issue. Posting empty fields always results in an unchanged password (no matter if I click on Change password or not).

Likewise, now in Safari, Chrome and Firefox.

Any further information to add to this @nils?

I can reproduce this behaviour on multiple Symphony 2.2.1 installs. It only happens using Safari and it doesn't seem to be JavaScript related as it also happens with JavaScript disabled.

Steps to reproduce

• Edit an author
• Change the mail adress (it has to be different to the old one to trigger the error)
• Save changes
• The Old Password field that has not been touched while editing displays this error: "Wrong password. Enter old one to change email address.". New Password and Confirm New Password are empty.

Environment

We are using the following extensions:

• Cross-Site Scripting (XSS) Filter 1.0
• Date and Time 2.0RC1
• Debug DevKit 1.1
• Documenter 1.0RC1
• Don't Drop! 1.3
• Dump DB 1.08
• Field: Output 1.2
• Field: Page Select Box 1.3
• Field: Reflection 1.0.11
• Field: Select Box Link 1.19
• Field: Text Box 2.2
• Field: Unique File Upload 1.3
• Image Index Preview 1.0
• JIT Image Manipulation 1.09
• Language: German 1.3
• Maintenance Mode 1.4
• Order Entries 1.9.6
• Profile Devkit 1.0.4
• Safari Uploads 1.2
• Subsection Manager 1.2dev
• Text Formatter: Markdown 1.13
• Unpublished Filter

Aha. Changing the email address triggers the "issue"! It says:

Wrong password. Enter old one to change email address.

So I need the password to change the email address. Basically that's OK, isn't it?

It's just the UX which is strange...

No, that doesn't make sense at all because a developer should be able to change all author profiles and of course he shouldn't know all passwords :)

So basically the current behaviour is 'correct', it's just that you are proposing that developers should be able to change email addresses of Authors without knowing the Author's passwords.

I'm fine with that.

Are you sure that the current behaviour is intended? It's new to me that Symphony ever required a password for changing your own profile.

I can't say I've ever had to do it before, but it has been in the code since December 2008, so I'd say it's intended :)

Alistair implemented in August 2009 the ability for a Developer to be able to change account information without requiring a password (unless it is their own account).

So to double check. Are you logged in as a developer? Are you changing other Author's details or your own? Are you sure the browser is not autofilling the password fields?

So to double check. Are you logged in as a developer?

Yes, I am.

Are you changing other Author's details or your own?

My own.

Are you sure the browser is not autofilling the password fields?

I've tried two things to verify that:

• Clicking on Change Password didn't show any pre-filled fields.
• Disabling JavaScript and reloading the page didn't show any pre-filled fields either.

So, Safari doesn't seem to autofill anything.

In my opinion the current behaviour is illogical. There are two possible solutions I see:

1. Authors are only allowed to change their own details - no password needed. Developers are allowed to change everything - no password needed.
2. Password verification is mandatory but it pops up in some kind of modal box: developers are asked to enter their own password (not the author's password) to confirm the change. Authors are only allowed to change their own details.

Ah, so this only happens when editing your own Author record.

I thought you meant editing other Authors records as developer (which works).

Solution 1 is fine for me, it's a 30 second change to implement as well (which is nice and saves us having to involve UX to do some sort of modal styling/javascript).

What do the others think? I have a feeling there might of a been a reason for this 'sanity check', but it's before my time to know what it was ;)

The behaviour had been sort of intentional but not entirely. Back in the days of Symphony 2.0, the only difference between authors and developers was that developers could access the Blueprints menu. For those that still remember it, authors and developers were able to change between roles.

Symphony 2.0 user permission was essentially only single level. We had the view of adding a user access extension further down the track. Since every user could be a developer, the decision was to ensure all changes must be made by the user themselves. If the user forgets their password, they should reset through the login form. In hindsight it was not an ideal solution, alas, it made history and that is–as they say–that.

Shortly after, the issue of author v.s. developer permissions was raised among the community and the decision was to further segregate the roles between an author and developer. Authors were no longer able to switch to a developer role and developers ought to be able to change author settings without passwords.

As new versions are released, bits and pieces of this logic was updated. The behaviour you see now is old logic that is still hanging around inside a new system.

I agree with Nils that the behaviour doesn't make all that much sense as it's asserting password essentially for the wrong reason in the current set-up. I agree with Brendan that solution 1 is the preferred method.