add configurable option for start and end date/time for comment period

[allisonmuise]

Add configurable option to define the date and time when the comment period opens, and the date and time when commenting ends. This should also include selection of the time zone as well.

Heard this from multiple users at UC 2018 where comment periods have specific duration and someone needs to sit there and count seconds to click the toggle at the right moment.

Backwards compatibility with the existing open/close toggle should be considered.

[ashishchoure]

@allisonmuise

As per our understanding, we need to expose option to select the start date and end date along with the time for comment submission. However, the ArcGIS online configurable parameters do not have the option to include a date time picker in the config panel.

Please let us know your thoughts on this ticket.

[allisonmuise]

@ashishchoure I will speak to Kelly about adding a parameter type to support this

[allisonmuise]

@ashishchoure what do you think about the time zone request? Is this necessary, or can we use the time zone of the computer of the configurer and store the value as UTC?

[ashishchoure]

@allisonmuise

Correct. We will store the date in UTC using the current time zone.

[allisonmuise]

@ashishchoure ok, then please ignore the request for this to be configurable

[ashishchoure]

@allisonmuise

We have implemented this ticket. However, wanted to confirm the approach for backward compatibility.

• If the user configures the app and comment start and end date/time keys doesn't exist/empty/null then we will only honor the reporting period flag.
• If both reporting period flag and comment start and end date/time keys exist, we will first check if reporting period flag is "open" and then will check if current date is in between the comment start and end date/time.

Question:

• In the current approach, the current date will be validated only if start and end date is configured. But what if only start or end date configured. Do you want us to handle these cases?

Please let us know your thoughts on this approach.

[allisonmuise]

@ashishchoure I think we are on the same page, but I'd like to build your list out to a few more scenarios (including only start OR end) to make sure we are covering everything.

I am assuming that in the configuration UI the new datetime parameters are going to replace the existing open/closed parameters. Am I correct to believe that we must maintain the variables in the back end in order to maintain backwards compatibility?

• If the app doesn't have an open/closed flag configured, assume the period is always open (to cover apps configured before we added the current flag)

• if the app has an open/closed flag, but not a start/end datetime, follow the status of the flag

• if the app has both a start and end datetime configured, and the current datetime is between these commenting is open. If the current datetime is outside these it should be closed.

• if the app has only a start datetime, commenting should be closed prior to this datetime, and open afterwards. If there is an open/closed flag value it should be ignored in favor of the configured date/time value.

• if the app has only a end datetime, commenting should be open prior to this datetime, and closed afterwards. If there is an open/closed flag value it should be ignored in favor of the configured date/time value.

• If a user starts to enter a report/comment while commenting is open, but commenting closes before the report/comment is submitted....I'm not sure what we should do. Let me get back to you on this.

[allisonmuise]

UPDATE: in the last case described above - the form Submit button should also disable when the comment period is closed via date/time settings.

[ashishchoure]

@allisonmuise

Thanks for the detailed information. We are good with all the above cases and here our understanding from the above information :

If the app doesn't have an open/closed flag configured, assume the period is always open (to cover apps configured before we added the current flag)

• We are good on this point.

if the app has an open/closed flag, but not a start/end datetime, follow the status of the flag

• If start and end datetime is not configured we will honor the flag value.

if the app has both a start and end datetime configured, and the current datetime is between these commenting is open. If the current datetime is outside these it should be closed.

• We are good on this point.

if the app has only a start datetime, commenting should be closed prior to this datetime, and open afterwards. If there is an open/closed flag value it should be ignored in favor of the configured date/time value.

• We are good on this point.

if the app has only a end datetime, commenting should be open prior to this datetime, and closed afterwards. If there is an open/closed flag value it should be ignored in favor of the configured date/time value.

• We are good on this point.

If a user starts to enter a report/comment while commenting is open, but commenting closes before the report/comment is submitted....I'm not sure what we should do. Let me get back to you on this.

• We understood that we need to follow the same approach for "Submit a Report" button(report submission) along with comment.

Regarding disabling of buttons when reporting period expires in between the report/comment submission:

• We are planning to show the configured message We are no longer accepting new reports for this project.. On click of "Submit Comment" or "Report It" button.
• This is in sync with the current approach where the same message is shown on click of "Submit a Report" or "Comment" button when the reporting period flag is set to false. This will easy to implement and consistent throughout the application.

Please let us know your thoughts.

[allisonmuise]

@ashishchoure this all sounds good to me!

[allisonmuise]

@ashishchoure This is not working quite as I expected. I configured an app with the open date/time 15 minutes in the past, and the close time 15 minutes in the future (Current local time was 10AM, so I set the close time to 10:15). I saved the configuration and opened the app in another browser tab where I confirmed that I could submit a comment, vote, and submit a report. I waited until 10:16 and tried to vote, comment, and submit a report again. I was expecting to be denied because I'd set the close time to 10:15, but it let me perform all of these actions.

I also noticed that the open/close toggle is still on the configuration panel. I was expecting this to be removed and replaced with the date/time parameters. Is this possible?

(we can discuss more tomorrow)

[allisonmuise]

@ashishchoure Kelly has checked in a fix for this to devext. Should be available tomorrow morning by around 430 AM PST

[ashishchoure]

@allisonmuise

Thanks for the update. We will test the functionality at our end, do some minor code changes discussed in the call and we will keep you updated.

[ashishchoure]

@allisonmuise

We are seeing some issues in the configuration panel for date/time fields.

• Even after settings the values to date and time field the date time picker shows empty values after refreshing the configuration panel.
• If user clicks on save with empty values, the previously configured (if the values were configured) date/time values are still present in the configuration.

[allisonmuise]

@ashishchoure I have passed this along to Kelly

[allisonmuise]

@ashishchoure fix should be installed in tonight's build

[shoe913]

Verified