End time not used for automatic checkout when typical stay is 0 minutes (instead: 15 minutes)

[jkrwdf]

Avoid duplicates

• [X] Bug is not mentioned in the FAQ
• [X] Bug is specific for Android only (? cannot check, no iOS)
• [X] Bug is not already reported in another issue

Technical details

• Device name: Google Pixel 3 XL
• Android version: 11
• App version: 2.0.4

Describe the bug

An event of type "Event" mandates that the owner sets a "Start" and an "End" date, otherwise it cannot be saved. However, the "Typical Stay" value is pre-set with "00:00 hrs" and can remain on this value.

When now a guest checks in to this Event, then the information about the "End" of the event is completely unused, instead an automatic checkout time of 15 minutes (sic!) is proposed:

Due to this, the clients are automatically checked out after this time.

Guests can of course later on adapt this time, but I fear this will happen only seldom.

Therefore I consider this as a bug, not as a Wishlist item. It will cause unwanted early check-outs and therefore missed notification targets.

Steps to reproduce the issue

Ups, already given above.

Expected behaviour

I propose that when the owner of the "Event" specified no "Typical Stay" value (which is currently the default), then the guest CWA shall use the "End" time of the event for automatic check out.

To be honest, this is IMHO the only reason why the "End" date is maintained at all (the "Start" time at least has the effect that guests, when checking-in earlier, get a message "The event has not yet started, do you want to check in anyway", or similar).

And maybe "Event"s shall not have a "Typical Stay" at all. For them, we already have events of type "Place".

---

Internal Tracking-ID: EXPOSUREAPP-6764

[Ein-Tim]

Behavior under iOS:

"Place": Typical stay is pre set to 2h, it can't be 0. "Event": Typical stay can be deactivated, if it's activated it's set to 15 min.

-> Android should be aligned to this, I guess.

[heinezen]

@jkrwdf

Thank you for the report. We have notified the developers about this by creating an internal Jira ticket EXPOSUREAPP-6764.

---

Corona-Warn-App Open Source Team

[heinezen]

@jkrwdf @Ein-Tim

iOS and Android should behave the same way now. Please check if the issue is fixed.

---

Corona-Warn-App Open Source Team

[jkrwdf]

The CWA version available in Google Play Store for me as Android user is 2.4.3 and shows the same behavior (Even default "Typical Stay" is 00:00, and when not explicitly changed by event owner, CWA clients check in with 15 minutes) as reported on April 24th.

As the "Fix 2.3" label was assigned, I classify the check as "Not successful".

[vaubaehn]

I also can confirm: the issue is not fixed using CWA 2.5.1 Reproduced:

1. Created event with regular check-out time set to 00:00
2. Scanned QR code
3. Automatic check-out time is pre-set to 00:15.

[Ein-Tim]

I think the problem is here that it shouldn't be possible to create an event that has a typical stay time of 0 minutes. It should also not be possible to say that you want to automatically get checked out after 0 minutes.

At least this is the behavior under iOS, it's not possible to have a typical stay time of / automatically check out after 0 minutes.

[heinezen]

@jkrwdf @vaubaehn

Thanks for checking. I'll forward this to the dev team.

---

Corona-Warn-App Open Source Team

[vaubaehn]

@Ein-Tim

I think the problem is here that it shouldn't be possible to create an event that has a typical stay time of 0 minutes. It should also not be possible to say that you want to automatically get checked out after 0 minutes.

At least this is the behavior under iOS, it's not possible to have a typical stay time of / automatically check out after 0 minutes.

and also referring to https://github.com/corona-warn-app/cwa-documentation/issues/657 :

My understanding how "events should work" is as follows: If you set start time and end time, but you deactivate "typical time to stay" for an automatical check out before the end time as the event creator, then a user should be checked in when scanning the QR code, and be (automatically) checked out at the end time of the event. This is useful where you have "short" events with a defined timeframe, where users usually don't go out before end time, e. g. a movie in a cinema, a school lesson, etc. But if you are creating a somehow "longer" event with a definded timeframe, e. g. a vernissage that starts at 10:00 and ends at 18:00, it can be useful to enter a "typical staying time" when you have experiences how long your guests usually stay, e.g., 2:00 hrs. A user who accepts the automatic check out after 2:00 hrs should be checked out automatically at 16:00 when he checked it at 14:00. A user who checked in at 17:00 and accepted the automatic check out after 2:00 hrs should nevertheless be checked out at 18:00 as the vernissage ends at this time. A user who checked in at 11:30 but did not accept the automatic check out after 2:00 hrs should also be checked out at 18:00 accordingly.

The question is now, how to "deactivate the automatic check out/typical staying time": in Android I would assume it's done by setting the "typical staying time" to 00:00. If this is not possible in iOS, I would think it's a CWA iOS bug. The Android bug here is, that an automatic check out/typical staying time is set to 00:15 after scanning QR code, even it was set to 00:00 when creating the QR code.

So, probably it's an interesting mix-up of different bugs in iOS and Android CWA?

[Ein-Tim]

Hi @vaubaehn

Thanks for your detailed and long comment! I agree with you in all points & this is also how I would expect the event-registration feature to work, but apparently it is different. Everything what follows is only tested under iOS on app version 2.5.

If you set start time and end time, but you deactivate "typical time to stay" for an automatical check out before the end time as the event creator, then a user should be checked in when scanning the QR code, and be (automatically) checked out at the end time of the event.

Only if you create a QR-Code of the type "Event" you can deactivate the automatic check out during the creating process. However, if a user scans the QR-Code, he still has to enter after which time he wants to be automatically be checked-out. There is no way for the user to be checked-out at exactly the end time of the event, since there is no option "Check me out when the Event ends".

[…] user who checked in at 17:00 and accepted the automatic check out after 2:00 hrs should nevertheless be checked out at 18:00 as the vernissage ends at this time.

This is, again, how I'd expect it to work, but it doesn't. In the example the user would currently still get checked out after 2 hours and not at 18:00h.

A user who checked in at 11:30 but did not accept the automatic check out after 2:00 hrs should also be checked out at 18:00 accordingly.

As said above, there is no way for a user to "not accept the automatic check out" currently. The user would have to manually enter the hours until 18:00h.

The question is now, how to "deactivate the automatic check out/typical staying time": in Android I would assume it's done by setting the "typical staying time" to 00:00. If this is not possible in iOS, I would think it's a CWA iOS bug.

Mh, yeah. But it would be a bit difficult for the user to find this. I think it's correct that you can't set a typical staying time of 00:00. There should be an extra option "Check me out when the Event ends" (or similar), which the user can activate instead. Under iOS, if you use the picker and set it to 00:00, it jumps to 00:15 min and takes this value. Under Android I could imagine that it also takes 00:15 min, but does not show this to the user correctly.

The only situation where I think the start and end time is really used is this: You scan a QR-code of an Event before the Event starts or when the Event is already over. Then the app shows this:

Not yet started	Already over

[vaubaehn]

Hi @Ein-Tim , thanks for your valuable testing! For me it's not clear at the moment, if there are simply functions not implemented that could/should be expected to work (otherwise "event" in contrast to "place" does not make much sense imho), or whether there are a series of bugs?

@dsarkar and @heinezen Could you help us out here? How should it work actually?

[dsarkar]

Dear @jkrwdf, dear community,

thanks for reporting and discussing this issue. With release 2.27 this issue has been resolved, therefore this issue has been closed.

Best wishes, DS

---

Corona-Warn-App Open Source Team

[Ein-Tim]

Nice to have you back @dsarkar!

Maybe you could share some infos to which extent you will be available again?