Closed Bug 470577 Opened 11 years ago Closed 9 years ago
Can't confirm actions
If I try to rollback an edit, I get asked to confirm. When I click on the confirm button, it does nothing. I'll provide a screencast.
<http://ilias.ca/sumo/norollback.swf> [3.9M] look at the status bar
confirm button doesn't work on forums either so we can't delete posts. I think it has to do with http:// because it works if you manually switch to https:// (at least sometimes).
OS: Mac OS X → All
Hardware: x86 → All
Summary: Can't rollback edits → Can't confirm actions
And we can't unsubscribe from e-mail notifications.
Assignee: nobody → smirkingsisyphus
Target Milestone: --- → 0.8.1
Can someone provide me with admin rights on support-stage (or just a level I can test rollbacks with)? I'd like to do a few tests quickly. Off the top of my head, if tickets are failing, it's probably due to something with the sessions especially if sometimes https works instead of http. I thought tikiwiki had a tiki_sessions table to take care of the transfer from https to http (the same user would typically get a different session id for https and http), but maybe it isn't working properly? Nelson this was originally reported when the fix for Bug 470516 was committed to svn. Any ideas?
Oops. Username on stage/production is ecooper.
Tickets (which are the confirm pages) seem to be working properly on support-stage for me. Is this something happening only on production for everyone?
So, this is a production only problem. I think it's related to our current https troubles, specifically bug 470517. I'm not sure what course of action to take since I can't actually test on production to see what's causing the ticketing (the confirm pages) to fail. Ticketing in tikiwiki is pretty simple process. The current time is saved to session variable in PHP and a random ticket is assigned to the user via the user preferences. When you confirm an action by pushing submit, if the session variable is set, too much time hasn't passed (checked via the time saved in the variable), and the tickets match, the action is carried through. If the confirm page just keeps reloading, it's probably because the session variables are failing to save for whatever reason.
I was able to confirm deleting a watch via https://support.mozilla.com/tiki-user_watches.php?hash=hash many times. Are any other confirm pages working? If all of sumo will be falling under SSL, a separate bug needs to be filed to update the notification templates which have http:// hardcoded (or so I think).
(In reply to comment #9) > I was able to confirm deleting a watch via > https://support.mozilla.com/tiki-user_watches.php?hash=hash many times. > > Are any other confirm pages working? It's touch and go. I tried to remove a permission from a category last week. Tried many times on one day, then tried the next day, and it worked.
Would it be possible for you to keep an eye out today and tomorrow on what works and when it doesn't? I know it's a bit of a hassle, but being that this is a production-only problem I don't have much recourse in doing basic troubleshooting to see what's what and when. As of right now, confirm pages have worked +10 times when deleting watches as per comment 9.
So, what's the word on this? If it is still failing, I need steps to reproduce (namely what action led to the confirm page) and the html of the form on the page. It's possible, although highly unlikely, that a smarty pre-filter is failing. As I've mentioned, I haven't run into this on production yet, but all I've been able to test are deleting watches.
Ran into this today. Go to <http://support.mozilla.com/tiki-assignuser.php?assign_user=Chris_Ilias_user>, and remove that user from Approvers. HTML source is attached.
I'm currently writing a selenium test to automate a surf to the confirm page to see if I can isolate this off of production (staging/local). It's sort of taken a backseat to the other major bugs, but if this is still a frequent hazard, please let me know so I can dedicate more time to it.
Target Milestone: 0.9 → 1.0
(In reply to comment #15) > It's sort of taken a backseat to the other major bugs, but if this is still a > frequent hazard, please let me know so I can dedicate more time to it. It is. We've been getting spam in article comments, and the inability to delete it is bad.
Target Milestone: Future → 1.2
Not done for 1.2, very important for 1.3.
Target Milestone: 1.2 → 1.3
Eric, is there any more info you need for this bug? It's urgent that I rollback https://support.mozilla.com/en-US/kb/Options+window+-+Main+panel but this bug is preventing me from doing that right now. I'm going to copy/paste from an earlier revision.
Are you logging in via 'Log in' or from things like staging pages?
I have it set to remember me, so I didn't have to log in today. I don't remember which page I used. I'll try logging out and testing it.
I just tried logging in and navigating the admin pages to http://support.mozilla.com/tiki-assignuser.php?assign_user=Chris_Ilias_user to remove Chris_Ilias_user from locale leaders. Tried it via login link and via staging copy URL. Both times it worked.
Heh, things got magically fixed by 1.2?
Definitely not, because I ran into this bug when trying to rollback the edit to https://support.mozilla.com/en-US/kb/Options+window+-+Main+panel earlier today. There are actions that I would try midday that do not work, then when I try again late at night, it would work.
Here's some interesting info regarding this bug: Whenever I experience this bug, I can switch from Firefox/MacbookPro/broadband connection to Safari/iPhone/3G connection, and it works 100% of the time *so far*.
I just had to remove a comment, so I tried switching to Safari (same connection/computer). It worked. This may be something specific to Firefox.
Well, doesn't that make us special?
Stephen can you try this on a variety of browsers and let us know the results?
Assignee: jsocol → stephen.donner
(In reply to comment #27) > Stephen can you try this on a variety of browsers and let us know the results? Yes, doing so today!
So, I don't know what's happening here, but I was *unable* to reproduce using: * Firefox 3.5.2 * Firefox 3.0.13 * IE 8 * Opera 10 (just released!) * Safari 4 * Google Chrome All Windows, but still; Vishal, could you take a look? Thanks!
Severity: major → normal
Status: NEW → ASSIGNED
Priority: P1 → --
Target Milestone: 1.4 → 1.5
In the Contributors forum, cor-el mentioned something interesting about this bug. Having to re-login fixes this, suggesting that it might be an authentication issue. https://support.mozilla.com/en-US/forum/3/487421?#threadId487478
If it's consistent to reproduce, perhaps it would be good to see if how you log in has anything to do with it. If it's not, could it be about corrupted session data?
If I'm editing something in the admin panel or testing, I tend to use the login link on the front page. Aside from that, I usually login wherever I get a prompt (accessing a staging copy) and use the "remember me" checkbox.
This is a mass change. Every comment has "assigned-to-new" in it. I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.
Status: ASSIGNED → NEW
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.