Email to advisors not working in the absence of a committee member controlled vocabulary

[smutniak]

This is a draft which needs refinement to correctly describe the problem.

There are two hosted sites which do not have a controlled vocabulary for their advisors and committee members. The admins at these sites wish to allow freeform email entry as permitted by Vireo3.

The default input type does not work nor was I able to get INPUT_TEXT or INPUT_EMAIL to work for the data and sites I tested with.

org.springframework.http.converter.HttpMessageNotReadableException: JSON parse error: Cannot construct instance of java.util.ArrayList (although at least one Creator exists): no String-argument constructor/factory method to deserialize from String value ('reitzer@utdallas.edu'); nested exception is com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot construct instance of java.util.ArrayList (although at least one Creator exists): no String-argument constructor/factory method to deserialize from String value ('reitzer@utdallas.edu') at [Source: (org.springframework.util.StreamUtils$NonClosingInputStream); line: 1, column: 139] (through reference chain: org.tdl.vireo.model.FieldValue["contacts"]) at org.springframework.http.converter.json.AbstractJackson2HttpMessageConverter.readJavaType(AbstractJackson2HttpMessageConverter.java:391) ~[spring-web-5.3.24.jar:5.3.24] at org.springframework.http.converter.json.AbstractJackson2HttpMessageConverter.read(AbstractJackson2HttpMessageConverter.java:343) ~[spring-web-5.3.24.jar:5.3.24] at org.springframework.web.servlet.mvc.method.annotation.AbstractMessageConverterMethodArgumentResolver.readWithMessageConverters(AbstractMessageConverterMethodArgumentResolver.java:185) ~[spring-webmvc-5.3.24.jar:5.3.24] at org.springframework.web.servlet.mvc.method.annotation.RequestResponseBodyMethodProcessor.readWithMessageConverters(RequestResponseBodyMethodProcessor.java:160) ~[spring-webmvc-5.3.24.jar:5.3.24] at org.springframework.web.servlet.mvc.method.annotation.RequestResponseBodyMethodProcessor.resolveArgument(RequestResponseBodyMethodProcessor.java:133) ~[spring-webmvc-5.3.24.jar:5.3.24] at org.springframework.web.method.support.HandlerMethodArgumentResolverComposite.resolveArgument(HandlerMethodArgumentResolverComposite.java:122) ~[spring-web-5.3.24.jar:5.3.24] at org.springframework.web.method.support.InvocableHandlerMethod.getMethodArgumentValues(InvocableHandlerMethod.java:179) ~[spring-web-5.3.24.jar:5.3.24] at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:146) ~[spring-web-5.3.24.jar:5.3.24] at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:117) ~[spring-webmvc-5.3.24.jar:5.3.24]

This error could not be replicated by Kevin but he encountered other errors with all but INPUT_EMAIL. I was unable to get INPUT_EMAIL to work. While I could enter emails on the form they were not reflected in a field_value.

It may be that entry appears to take place as it is allowing typeahead but no actual value backs what is typed for the email.

[cstarcher]

I was able to confirm that entries into INPUT_CONTACT field types do not save without an associated controlled vocabulary.

The temporary solution is to create a blank controlled vocabulary and add it the field profile. This will allow free entry into the field and will save to the submission.

[kaladay]

I would note that I did the following in my testing:

1. Create a new database.
2. Use that database via mvn clean spring-boot:run -Dspring-boot.run.arguments="console" -Dprofile="development"
3. Login using the test account, Jack Daniels.
4. Create "Awesome College" in Organizations.
5. Select "Awesome College", navigating into Manage Workflow and then to Document Information.
6. Edit Committee Chair, changing Input Type to INPUT_EMAIL and select "clear" button/link under Controlled Vocabulary so that no CV is selected (It should say (None)).
7. Edit Non-Chairing Committee Members, changing Input Type to INPUT_TEXT and select "clear" button/link under Controlled Vocabulary so that no CV is selected (It should say (None)).
8. Go to Application Settings and set Submission Availability to "Open" and Multiple Submissions to "Yes" (Multiple submissions makes testing easier).
9. Go to the /submission/new page, creating a new Submission under "Awesome College".
10. Skip to "Document Information" tab, and set Title to "find me" for easier searching.
11. On that same page, se the Committee Chair to an e-mail address like you@example.com.
12. Set the Non-Chairing Committee Members to some random string like aa bb cc.
13. Click the Continue to File Upload button.
14. Go back to the "Document Information" tab and I see the changes I saved as being present.
15. Go to the "Confirm and Submit" tab and see the changes I saved as being present.
16. Go to the Admin List page, find and select the find me Submission and then try changing the Committee Chair to a different e-mail to and see that it changes.
17. Do the same thing for the Non-Chairing Committee Members.
18. Refresh the page to confirm that the changes are saved.
19. Change the Submission Status into Under Review and then view the Faculty Review URL to further confirm that the changes were saved.

I see that in all cases the changes are being saved. Please try to repeat this process yourself to confirm/deny the same behavior.

The commit hash I am working on for this test is 61fb5873989eee667951f7b80244fa4f91c084ea, which is the current main branch (and also the v4.2.5 release tag) at the time of this posting.

Some possible differences are that I am using a Postgresql database rather than H2.

[cstarcher]

I can confirm that following the steps above by @kaladay for free text input into INPUT_EMAIL and INPUT_TEXT does save without an associated controlled vocabulary.

I will also point out that the Vireo 4 documentation states that INPUT_CONTACT is

"Used with a controlled vocabulary with the Contact column populated by email addresses."

Requiring a Controlled Vocabulary for INPUT_CONTACT is designed behavior. The difference between INPUT_CONTACT and INPUT_CONTACT_SELECT is that the latter does not allow unique value entry. However, both require a controlled vocabulary.

If an email address is the only desired input for a field value and unique values are required without an associated controlled vocabulary, INPUT_EMAIL should be used for the input type. If a name and an email address are both desired inputs for a field value and unique values are required without using a controlled vocabulary, INPUT_CONTACT may be used with an associated empty controlled vocabulary.

Regarding the original post by @smutniak, it may be necessary to further test the functionality of INPUT_EMAIL and INPUT_TEXT in a production deployment.