[MAGNOLIA-2656] Unable to delete superuser email address, when logged in with superuser Created: 10/Mar/09  Updated: 23/Jan/13  Resolved: 10/Jun/09

Status: Closed
Project: Magnolia
Component/s: admininterface
Affects Version/s: 3.6.3
Fix Version/s: 4.1, 3.6.6, 4.0.2

Type: Bug Priority: Blocker
Reporter: Olivier Marti Assignee: Jan Haderka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File error.log    
Issue Links:
dependency
depends upon MAGNOLIA-2674 User permissions are not checked cons... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

When I try to delete the email-address of superuser while logged in with himself I get an error attached. Workaround is to log in with another user which has superuser rights and delete the superuser address with this one.



 Comments   
Comment by Magnolia International [ 10/Mar/09 ]

Can't reproduce on demoauthor through the profile link on top-right corner. Was able to specify the email for superuser(myself), save, reopen, blank the field, and re-save without any issue.

Comment by Olivier Marti [ 10/Mar/09 ]

Demoauthor is 4.0 RC 3...so in 3.6.3 I think I'm forced to go trough Security -> System Users -> Superuser
I was able to recreate the error in several 3.6.3 installations.

Comment by Magnolia International [ 11/Mar/09 ]

Hmm indeed. That is strange. Modifying the address works, not removing it.
Jan - any clue?

Comment by Jan Haderka [ 12/Mar/09 ]

I'm not able to reproduce this on clean 3.6.3 installation. Is it possible that the instance in question have been upgraded from some older version?

Comment by Olivier Marti [ 12/Mar/09 ]

Yes, actually all of the ones I checked the issue in.

Comment by Jan Haderka [ 31/Mar/09 ]

Done as of r24083 on trunk, r24085 on 4.0 branch and r24086 on 3.6 branch.

Comment by Magnolia International [ 08/Jun/09 ]

version handler in 3.6 branch is not in synch with 4.0 branch nor trunk - registering the task for 3.6.5, while 1) 3.6.5 has already been released !! 2) the other branches register this task for 4.0 !

Comment by Jan Haderka [ 10/Jun/09 ]

Indeed. This was necessary to allow applying the fix for all 3.6, 4.0 and 4.1 branches. Since the 4.1 branch was not released yet at the time and so was not the 4.0.2 It was possible to keep the update task in sync there. This was not possible for 3.6 branch (could not introduce the 4.0.2 update task there, as well as could not add 3.6.x task onto 4.x branch). Anyway the two tasks that are executed takes care of the things and can be safely executed multiple times.

Comment by Jan Haderka [ 10/Jun/09 ]

Changed update task execution for 3.6 branch to 3.6.6 and commented on all branches to explain discrepancy between when tasks are applied.

Generated at Mon Feb 12 03:38:49 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.