Closed Wei940127 closed 9 months ago
Should we make 2 issues? Since the instruction not showing is different than the email not going out?
@imrryr I would. I'm going to try to get to these today, I've been bogged down with meetings.
@imrryr this is addressed in PR #1407
The lockout only works when the participant keeps the page open, once they log out and log in again using their ID, the timer resets from the beginning. Please see the below image, I used the same ID, and after logging in using the experiment link, the timer resets from the beginning. lockouttest.zip
I tested it and this seems not working. The issue is that if the participant logs out before the timer finishes, and then logs in again, the timer resets. So the participant must keep the page open until the timer finishes if they want to start Session 2.
@Wei940127 We tested this case earlier this week, so it looks like we may need more information, since as of last deployment, we cannot reproduce it.
As silly as it may seem could you post screenshots with the JavaScript console open of the timer before logging out and after logging out and back in.
Here is the screenshot at the beginning. This is the screenshot before logging out. And the screenshot after logging out and back in.
I assume you waited more than 2 minutes before resuming Wei.
So it appears to create the bug. Are you testing with a root file Rusty? That adds complexity to resuming, I imagine. Also Rusty, did you close the browser when you tested this previously. It needs to resume after the user has been gone many days, which requires the start time for the timer to be in the database and loaded when they come back. Currently, it appears to not save or load the prior time from the database.
Sorry if this was all obvious @James Haner @.***>
On Sun, Mar 3, 2024 at 10:49 AM Wei Chu @.***> wrote:
Here is the screenshot at the beginning. Screenshot.2024-03-03.104401.png (view on web) https://github.com/memphis-iis/mofacts/assets/54991536/428c3aed-d407-4a90-8a65-c09c0900b886 This is the screenshot before logging out. Screenshot.2024-03-03.104505.png (view on web) https://github.com/memphis-iis/mofacts/assets/54991536/2cee4086-d8a4-4ecd-bba9-4a69206b75e0 And the screenshot after logging out and back in. Screenshot.2024-03-03.104605.png (view on web) https://github.com/memphis-iis/mofacts/assets/54991536/1f6bf0ad-d5fa-40c8-a76e-814b4b015633
— Reply to this email directly, view it on GitHub https://github.com/memphis-iis/mofacts/issues/1404#issuecomment-1975227769, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDLPK7D6BHHJBMDRMVHXKDYWNICBAVCNFSM6AAAAABDP5XQKCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZVGIZDONZWHE . You are receiving this because you were mentioned.Message ID: @.***>
-- Philip I. Pavlik Jr. @.*** http://optimallearning.org/
No, this issue only happens before the timer finishes, if the participant quits in the middle of the timer counting down, and logs in again, the reset issue happens. I tried to wait more than 2 minutes to let the timer finish, in this case, after logging out and back in again, the procedure started from Session 2 directly.
Ahhhh... that is very different. You are saying if they log in early, it resets incorrectly (it should show the time remaining). However, if they log in after it expires, it works? Please confirm.
On Sun, Mar 3, 2024 at 11:21 AM Wei Chu @.***> wrote:
No, this issue only happens before the timer finishes, if the participant quits in the middle of the timer counting down, and logs in again, the reset issue happens. I tried to wait more than 2 minutes to let the timer finish, in this case, after logging out and back in again, the procedure started from Session 2 directly.
— Reply to this email directly, view it on GitHub https://github.com/memphis-iis/mofacts/issues/1404#issuecomment-1975235672, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDLPK4K7MNXADCAGLVPBOLYWNLZ5AVCNFSM6AAAAABDP5XQKCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZVGIZTKNRXGI . You are receiving this because you were mentioned.Message ID: @.***>
-- Philip I. Pavlik Jr. @.*** http://optimallearning.org/
When they log out after the timer expires, and then log in again, the timer doesn't reset. In other words, the 3-day condition requires our participants to keep the experiment page open and stay logged in for 3 days, anytime they log out before the timer expires, the timer will reset when they log in again.
OK, when you said it happens "only before the timer finishes," I misunderstood that it works after it finishes, even when logged out.
But I'm still a little confused by logout. Do they need to logout to break it, or will just closing the browser do break it. Normally people wouldn't be login out, so I assume you mean this happens after closing the browser when the timer is still running?
Yes, it happens when they close the browser when the timer is still running.
I just tried it again. So I closed the browser when the timer was 1min, 40s, then logged in again immediately (took about 10 seconds), and the timer started from 2 minutes. But if I closed the browser when the timer was 1min, 40s, and waited for 2 minutes, then logged in again the timer was finished and the procedure started from session 2.
Wait, this is what I thought previously, but you said no, I thought.
So it is only broken when the student returns early? Have we concluded that now? It works if the timer is allowed to pass the 2 minutes before returning? Please answer each of these questions individually with a yes or no. ( I expect yes, yes, yes or I don't get it yet.)
Yes for all three questions.
OK, this is probably why @JRustyHaner couldn't reproduce the bug. The problem is when the student returns early, which resets the timer, but he likely checked if it worked when the timer was past.
@imrryr Another race condition. The first time the page is rendered, Meteor hasn't had time to get the current user's existing lockout timers as a response from the server side code, so it assumed there wasn't an existing one and reset the timer.
In the fix, we await the setting of the timer, so the client has to get a response before continuing.
Another note. We round the lockout time up to the nearest minute when reloading. This might explain why it feels like the lockout it 'resetting'
Ahhh, can we not do that? There is no clear reason to, so it seems like a minor bug.
On Mon, Mar 4, 2024 at 9:58 AM August White @.***> wrote:
Another note. We round the lockout time up to the nearest minute when reloading. This might explain why it feels like the lockout it 'resetting'
— Reply to this email directly, view it on GitHub https://github.com/memphis-iis/mofacts/issues/1404#issuecomment-1976911827, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDLPK6HMXIB72O7E4USQ53YWSK3RAVCNFSM6AAAAABDP5XQKCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZWHEYTCOBSG4 . You are receiving this because you were mentioned.Message ID: @.***>
-- Philip I. Pavlik Jr. @.*** http://optimallearning.org/
@imrryr yep, we can do that. Making it round up didn't make much sense to me either.
The Lockout unit doesn't work when participants close the page after finishing the Part 1 section and return back.
Also the "unitinstuctions" following the "turkemail" did not show at the end of the Part 1 section.
"turkemailsubject": "Link for 3$ Bonus for Turk HIT", "turkemail": "\r\nDear Amazon Turk Worker,\r\n", "unitinstructions":"<p><strong>Congratulations on completing Part 1 of the experiment!</strong> <br /><br /> To ensure that your assignment is approved and you receive the $5.00 payment, please enter the code <strong>'PAIRWUI'</strong> into the Amazon Mechanical Turk website for this HIT and submit your response now. ", "unitname": "Lockout unit", "deliveryparams": [ { "lockoutminutes": "1440" } ] },
Here is the package used for testing. LMRT3lockout.zip