Knowledge Base Software
10 years ago
8 years ago


(Reporter: cilias, Unassigned)




Firefox Tracking Flags

(Not tracked)



(1 attachment)



10 years ago
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.

Comment 1

10 years ago
<> [3.9M] look at the status bar

Comment 2

10 years ago
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


10 years ago
Keywords: assertion

Comment 3

10 years ago
And we can't unsubscribe from e-mail notifications.
Keywords: regression

Comment 4

10 years ago
Not good.
Assignee: nobody → smirkingsisyphus
Target Milestone: --- → 0.8.1

Comment 5

10 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

10 years ago
Oops. Username on stage/production is ecooper.

Comment 7

10 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

10 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

10 years ago
I was able to confirm deleting a watch via 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).

Comment 10

10 years ago
(In reply to comment #9)
> I was able to confirm deleting a watch via
> 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

10 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.


10 years ago
Target Milestone: 0.8.1 → 0.8.2

Comment 12

10 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.


10 years ago
Duplicate of this bug: 441230

Comment 14

10 years ago
Created attachment 358318 [details]
html source

Ran into this today.
Go to <>, and remove that user from Approvers.
HTML source is attached.


9 years ago
Target Milestone: 0.8.2 → 0.9
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


9 years ago
Target Milestone: 1.0 → Future

Comment 16

9 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
Not done for 1.2, very important for 1.3.
Target Milestone: 1.2 → 1.3

Comment 18

9 years ago
Eric, is there any more info you need for this bug? It's urgent that I rollback 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?

Comment 20

9 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.

Comment 21

9 years ago
I just tried logging in and navigating the admin pages to 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?

Comment 23

9 years ago
Definitely not, because I ran into this bug when trying to rollback the edit to 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.


9 years ago
Priority: -- → P2

Comment 24

9 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*.

Comment 25

9 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.
Well, doesn't that make us special?


9 years ago
Assignee: smirkingsisyphus → paul.craciunoiu


9 years ago
Target Milestone: 1.3 → 1.4
Assignee: paul.craciunoiu → jsocol
Stephen can you try this on a variety of browsers and let us know the results?
Assignee: jsocol → stephen.donner
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!
Assignee: stephen.donner → nobody


9 years ago
Severity: major → normal
Priority: P1 → --
Target Milestone: 1.4 → 1.5
Target Milestone: 1.5 → Future

Comment 30

9 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.
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?

Comment 32

9 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.
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.
Last Resolved: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.