-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Backend Support for Dynamic Custom Fields on Joining Form - Design #69
Comments
Proposal - How we define and store questions - JSON We would have GET/PUT/POST endpoints for each queue that the UI would use to set, edit, and view the questions. Each custom_question would have these fields:
An example PUT call to set questions. A hypothetical saloon owner would use this to know what type of haircut, how many people etc:
Response (Also what you get when you
|
A sample joiner answer:
Json:
|
How other users might take it: A Restaurant Owner Could Feed the Menu as a question:
A printshop:
|
This looks good. Just one thing I noticed is the first object in the QUESTION_SET subquestions list doesn't have an id attribute. Is this intentional? It would break the structure, right?
And in the same object, there are ids in each of the dropdown options which we could maybe give a different name to avoid confusion. |
I've updated it. Yeah, I missed an id there. yes, we should give different names. I'm thinking |
Yeah, that'll work. |
I've updated the above posts with a |
@daltonfury42 The approach looks good |
Made a basic design of Queue settings field where we can incorporate this functionality. https://xd.adobe.com/view/99a3a298-8f0c-468a-6cf3-614e96f6f9f5-ef92/ |
@daltonfury42 Can i pick this story and start the implementation. I think design is done right ? |
Please. I was thinking about this over the weekend. These are my thoughts:
Then remaining task would be on the frontend side... We would have to define an interface that lets the users define and also another that lets users fill the form. Just to give you context, we want this queue management system to be a very generic product that anyone can use. So, a hospital might ask patient hospital related question (which department, patient age etc) , a restaurant might ask number of people, smoking/non-smoking etc. I was talking to a photocopy shop owner recently. He was pretty excited to use this to get people to submit print orders to the queue. Most people currently crowd at the shop front desk and documents are send to an email. So if there is a fair queue where you can submit orders, they can process more people faster. Remember the crowds at photocopy shops back in college before exams. :) Task 5 is for photocopy shop usecase, for people to upload files to be printed |
If the above looks fine to you, I'd say, split this into multiple PRs. Maybe c(1,2,3) can be one PR and 4, 5, 6 can be individual/separate PRs. |
We should also give creators the ability to modify forms for existing queues. As if there are long-lived queues, the requirements might change over time. We need to version these forms so that old answers are preserved. Another option for creators who recreate queues daily - it would be helpful for them to have their existing forms saved for reuse with their new queues. |
Yes, these two are super critical. @thehamzarocks After our versioning discussion, now I think we don't need to version, as the question is also included along with the answer. So these two would be easy to implement, I believe. |
@daltonfury42 What should be the new endpoint ? POST |
@thehamzarocks I'd favour |
@daltonfury42 What database are we using in PROD ? |
PostgreSQL |
H2 doesnt support JSONB, So I am planning to change from H2 to postgres on local too @daltonfury42 |
I see. I wanted locally running backends to connect to a H2 database so that it will ease development. What do you recommend? Local postgres or storing the data as string? cc: @thehamzarocks |
Hmm with H2, it’s very easy for new contributors to get set up. Also, unless we plan on doing operations on the json from within sql, I think it’s fine to store it as a string. As far as I can see, we’ll only be doing get/post operations on the forms from UI. And if we rely too much on Postgres JSON functionality, we’ll be tied to it forever. But if you see the need, then we can consider it. |
@pavan541cs let's store the json as string in DB, unless you think we should use jsonb |
|
@daltonfury42 Just a small change, I changed the input payload by adding questions at the parent level. Can you confirm if it is fine ? |
Currently when a person joins a queue, he is asked a fixed set of input data, (name and contact number). We want to give the queue owner the ability to define a set of custom set of questions. We need to let the admin set it in a way inspired from the Google Forms model:
We need to design this first.
The text was updated successfully, but these errors were encountered: