Closed
Bug 470577
Opened 16 years ago
Closed 14 years ago
Can't confirm actions
Categories
(support.mozilla.org :: Knowledge Base Software, task)
support.mozilla.org
Knowledge Base Software
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
Future
People
(Reporter: cilias, Unassigned)
References
Details
(Keywords: regression)
Attachments
(1 file)
22.54 KB,
text/plain
|
Details |
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.
Reporter | ||
Comment 1•16 years ago
|
||
<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).
Keywords: assertion
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.
Keywords: regression
Comment 5•16 years ago
|
||
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?
Comment 6•16 years ago
|
||
Oops. Username on stage/production is ecooper.
Comment 7•16 years ago
|
||
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?
Comment 8•16 years ago
|
||
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.
Comment 9•15 years ago
|
||
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).
Reporter | ||
Comment 10•15 years ago
|
||
(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.
Comment 11•15 years ago
|
||
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.
Updated•15 years ago
|
Target Milestone: 0.8.1 → 0.8.2
Comment 12•15 years ago
|
||
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.
Reporter | ||
Comment 14•15 years ago
|
||
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.
Updated•15 years ago
|
Target Milestone: 0.8.2 → 0.9
Comment 15•15 years ago
|
||
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
Updated•15 years ago
|
Target Milestone: 1.0 → Future
Reporter | ||
Comment 16•15 years ago
|
||
(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
Reporter | ||
Comment 18•15 years ago
|
||
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.
Comment 19•15 years ago
|
||
Are you logging in via 'Log in' or from things like staging pages?
Reporter | ||
Comment 20•15 years ago
|
||
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.
Reporter | ||
Comment 21•15 years ago
|
||
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.
Comment 22•15 years ago
|
||
Heh, things got magically fixed by 1.2?
Reporter | ||
Comment 23•15 years ago
|
||
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.
Reporter | ||
Updated•15 years ago
|
Priority: -- → P2
Reporter | ||
Comment 24•15 years ago
|
||
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*.
Reporter | ||
Comment 25•15 years ago
|
||
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.
Comment 26•15 years ago
|
||
Well, doesn't that make us special?
Updated•15 years ago
|
Assignee: smirkingsisyphus → paul.craciunoiu
Updated•15 years ago
|
Target Milestone: 1.3 → 1.4
Updated•15 years ago
|
Assignee: paul.craciunoiu → jsocol
Comment 27•15 years ago
|
||
Stephen can you try this on a variety of browsers and let us know the results?
Assignee: jsocol → stephen.donner
Updated•15 years ago
|
Priority: P2 → P1
(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!
Updated•15 years ago
|
Assignee: stephen.donner → nobody
Updated•15 years ago
|
Severity: major → normal
Status: NEW → ASSIGNED
Priority: P1 → --
Target Milestone: 1.4 → 1.5
Updated•15 years ago
|
Target Milestone: 1.5 → Future
Reporter | ||
Comment 30•15 years ago
|
||
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
Comment 31•15 years ago
|
||
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?
Reporter | ||
Comment 32•15 years ago
|
||
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.
Comment 33•14 years ago
|
||
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
Updated•14 years ago
|
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•