Ability to create forms and embed on a website (UXPROD-951)

[UXPROD-847] Ability to create forms and embed on a website Created: 06/Jun/18  Updated: 01/Mar/22  Resolved: 01/Mar/22

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Ability to create forms and embed on a website

Type: New Feature Priority: P3
Reporter: Hkaplanian Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: licenses
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Cloners
is cloned by UXPROD-951 Ability to create forms and embed on ... Open
Epic Link: Ability to create forms and embed on a website
Front End Estimate: XL < 15 days
Front End Estimator: Jakub Skoczen
Back End Estimate: Medium < 5 days
Kiwi Planning Points (DO NOT CHANGE): 5
Rank: Chalmers (Impl Aut 2019): R5
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R4
Rank: Duke (Full Sum 2021): R4
Rank: 5Colleges (Full Jul 2021): R2
Rank: FLO (MVP Sum 2020): R4
Rank: GBV (MVP Sum 2020): R4
Rank: hbz (TBD): R4
Rank: Hungary (MVP End 2020): R2
Rank: Lehigh (MVP Summer 2020): R4
Rank: Leipzig (Full TBD): R4
Rank: Leipzig (ERM Aut 2019): R4
Rank: TAMU (MVP Jan 2021): R2
Rank: U of AL (MVP Oct 2020): R4

 Description   

A "Google Forms" like functionality, which allows a form to be created inside FOLIO, and embedded on a website, and that would allow anything submitted through that form to end up in FOLIO as e.g.
. • a note on a specific or variable record (the record in question could be defined for the form as a whole, or a field filled out in the form could define on which record in FOLIO the note would end up)
. • a new task or new record (content from form would be turned into either of these)
— in addition to being able to send information to FOLIO, the form would support auto-suggestions for fields in which users have to fill out information that relates to a set of data in FOLIO — meaning any field where the task of the end user is to pick a database, a user, a request type, a vendor, or something else that exists as data points in the FOLIO setup. So if the form e.g. was meant to let people suggest purchases for selectors to verify, or for professors to suggest purchases that would go straight to acquisitions, then the form could tap into the data source used by acquisitions staff, to avoid the extra steps of emails being sent to acquisition staff; and acquisitions staff having to find the record in question; and contact the requester to verify that it's the same material; etc. etc.
— For this concept to work, people should be able to, in the long term, create and manage forms in a FOLIO app, and get the embed code through the FOLIO interface, that they could then place on an external website (FOLIO would have to control which domains it would accept input from, of course). And in the short term, should perhaps just be able to send information to FOLIO from custom made HTML forms, but by sending the form content to the right receiving entity in FOLIO, the information could thus be entered. The notion of auto-suggesting, could perhaps also be served the other way through javascript, if there is no forms provided by FOLIO to begin with. The latter, short term concept, would have few GUI implications in FOLIO, it seems to me, but would still require work on the relevant APIs.


Generated at Fri Feb 09 00:10:52 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.