As a Form creator, I want to define an expiration date for my form

• Type: Story
• Status: Closed
• Priority: Minor
• Resolution: Completed
• Affects Version/s: None
• Fix Version/s: 7.4.3.5 CE GA5, 7.4.13 DXP U1, Master
• Component/s: Forms
• Labels:
  • 7.4-must
  • 7.4-portal-ga6
  • fc_21_11
  • fc_21_12
  • forms_q4
  • mockups_matches_ac
  • team-bravo
• Epic Link: Polls Deprecation Alternative to Forms

Context:

When creating polls for users, one important form definition is an expiration date. Not allowing users to submit answers after the date is expired.

This feature is even more important with the deprecation of Liferay Polls.

Design Deliverables

Mockup

Acceptance Criteria

1 - Given a form admin,
when creating a form,
then I must be able to define an expiration date for the form

2 - Given a user filling a form,
when the form is expired,
then I must not be able to submit answers

3 - Given a admin in forms,
when seeing the list of forms,
then I must be able to identify the forms that are expired

4- Given* an user in forms in an expired form,
When the form has the partial results shared,
then I must still be able to see the partial results.

Definition of Done (DoD):

• All Acceptance Criteria were passed;
• Make sure that the expected automated tests were created (unit / integration / functional) and passed successfully;
• Code with peer review completed;
• Validated by QA, Product Designer and/or PM;
• No critical bug related to Story scope (ex.: similar of FP4, FP5);
• Make sure that all system documentation were updated (if necessary)
• Make sure that it has the extensions points needed to allow GS and customers to customize the feature (If applicable)

*Only if LPS-109667 is completed.

Ticket Updates

• We can't normalize the expiration date to UTC, because doing so would require the time to be stored as well and the "expiration time" is not being developed yet (check LPS-142800). Therefore, what is chosen in the form's settings is exactly what gets stored in the database, thus the form's expiration status will depend on the user's timezone (meaning, if two users from different time zones access a given form, it's possible that, to one of these users, the form is expired and, to the other, it is not. This is only possible if those two given users are in different dates of the calendar). This is exactly how the date validation feature behaves;
• For guest users that fill out a form that has an expiration date, Forms will consider their default timezone (UTC) to validate expiration status. This won't be an issue after LPS-142800 is finished (nor it was an issue on Polls), because once Forms starts to save both expiration date and time, a form gets expired at the same moment for every one in the world as detailed in point #2 of this comment;
• Currently, Forms doesn't allow to preview or autosave a form if its settings have some validation error (what is shown in the preview page is the form's last saved version or, if it doesn't have one, an error message saying the form is unavailable). For now, we will maintain this behavior, but it should be revisited in a future story (ideally, forms should be previewed regardless of its settings, but allowing so would bypass the "Save" button validation);
• Due to technical limitations, the expiration date will have its value erased every time the never expire checkbox is marked. For more technical in depth reasoning, check LPS-142989.
• After LPS-144206 was opened, we discussed what should be the expected behaviour and concluded that the admin shouldn't be able to edit the entries after the form is expired. A warning should be shown at the form entries letting the user know that you can't edit when the form is expired, and the "edit entry" option won't be showing in the dropdown. The mockup was updated following this new behaviour, and the message for the warning changed to "Warning: The Form is expired and is no longer available for editing or submitting new answers. Change the Form expiration date in Settings to Publish, Save or edit answers."