Changelog

Have something to say?

Tell us how we could make the product more useful to you.

Allow form edit by multiple users (internal remarks)

It would be useful to allow form edit by multiple users. Scenario Public User submits an application form Internal Staff 1 reviews the application form. He/She needs to add internal remarks to the form submitted for approval / review Internal Staff 2 reviews the internal remarks and add commentary to approve / reject the application request For future, opening the same form can see the whole history for audit / recording

Kelvin 12 days ago

💡 Feature Request

Built-In Scoring Features ( Research / User Feedback )

To allow configuration of specific questions for scoring would be a good feature for research / user feedbacks. Example (Form with 4 Questions): Q1 - Control Question Q2 → For scoring (e.g. A = 1pt, B = 3pts, etc…) Q3 - Control Question Q4 → For scoring Then, the scoring of each form can be calculated based on the scoring logics defined.

Kelvin 12 days ago

💡 Feature Request

Rejected

non-OpenAI llm endpoint support

I saw your .env supports https://docs.opnform.com/configuration/environment-variables Other Environment Variables Configuration Environment Variables Variable Name Description OPEN_AI_API_KEY API key for accessing OpenAI services. I use ollama and vllm in my local network for inference engines and they offer openai compatible communication. Please allow admins to configure .env a fqdns url and/or ip address to any different openai endpoint

sdf 22 days ago

2

💡 Feature Request

OIDC / OAuth2 support

I don’t use google and saw your .env appears can be setup for google oauth. Is this programmed to only support google or can any OIDC Oauth2 server be used? I use kanidm oidc for my personal docker selfhosted apps which handles identity user management and user auth and it also provides passkey and mfa security during the sign in. https://docs.opnform.com/configuration/environment-variables Other Environment Variables Configuration Environment Variables Variable Name Description GOOGLE_CLIENT_ID Client ID for Google OAuth. GOOGLE_CLIENT_SECRET Client secret for Google OAuth. GOOGLE_REDIRECT_URL Redirect URL for Google OAuth. GOOGLE_AUTH_REDIRECT_URL Authentication redirect URL for Google OAuth. Support for any OIDC OAuth2 server would be great to be able to specify in .env client_id client_secret redirect_url oidc_issuer_url Then people can use their own local oidc like https://github.com/kanidm/kanidm https://github.com/stonith404/pocket-id https://github.com/authelia/authelia etc

sdf 22 days ago

1

💡 Feature Request

First Class i18n Support - Multiple Language Support for a Single Form

So it would be great for single forms to be able to have multiple translation variations. Probably the cleanest way would be using i18n strings. Ideally we'd be able to specify the language tags ourselves, as it can be different per implementation e.g. en-US, en-UK, pt-PT, pt-BR etc. which is the ISO standard afaik. But some prefer to use e.g. just 'en' for US english, 'br' for Brazilian Portuguese. You could potentially make use of this: https://github.com/txty-io/texterify It has transitioned from a BSL to Apache v2 license. I've used their managed solution for years and it's been great. There is also inlang/opral: https://github.com/opral/monorepo/tree/main/inlang I only use paraglide from inlang/opral and it's quite nice for the front end, but not sure about their string management solution as I have not tried that. We'd need to be able to send the language tag to the form, particularly for embedded ones, to ensure it's possible to make sure the correct language can be loaded matching the currently used language on the site it is embedded on. Could perhaps have a json file that is downloadable for the primary language as well as uploading the translated versions. Could also potentially allow editing the strings inside the web panel and machine translations also. E.g. opnform.com/forms/uuid/en-US could use the en-US.json file, opnform.com/forms/uuid/pt-BR could use the pt-BR.json file etc. This would also allow using languages that aren't officially supported yet also, so we could provide our own translations for all form fields, success/error messages etc. Alternatively, it could be limited to languages officially supported. In that case, the translations would only need to cover the user modified parts. Just ideally would still use a url structure like above so it follows standards and all user cases could be covered.

form_enthusiast About 1 month ago

3

💡 Feature Request

Completed

Removed Fields - Fully Remove & Exclude from Duplicates + Improved Editing of Submissions

So I noticed that in the submissions section, it retains and displays previously saved fields that have since been deleted. This makes sense for a live form that already has submissions, for safety, ensuring info isn’t removed. That said, when I duplicate a form, which excludes all submissions, I don’t think it should include the removed fields. I created a template form and did a bunch of testing, but now, if I clone it, the other forms will always keep the removed fields as an option to display on the submissions page - despite no data now, or in the future, that will use those fields. It would be nice if this was excluded from duplicated forms and also for it to be possible to clean them out of existing forms (and accept that any submissions that used those fields, will lose data saved in those fields). Also, if a removed field is enabled to be visible on the submissions page, if you click the edit button - those fields will not be visible to edit. It would be useful to have this, in order to move data from the previous fields to the new fields and empty out the old fields. Also, to update the records, if you have a captcha on your form, it requires solving a captcha to edit each individual record (so that should also be removed).

form_enthusiast About 1 month ago

2

💡 Feature Request

Completed

Duplicate Form - Randomise Field IDs & URL

When duplicating a form, I think it would be better if the field ids were randomised as a safe default. Right now they use identical uuids. The url also uses the previous url and adds a suffix, though it’s easy to regenerate the url. Changing the field ids is a bit more tedious, cloning every individual field, removing the originals, renaming to remove ‘copy of ‘ and remaking any logic. So it would be nice if the field uuids were automatically randomised when cloned. Currently, with identical field ids, this means if forms are cloned between brands, workspaces etc. the form field ids can be used to definitively link forms together as having a common origin/owner/agency etc. Which is not ideal for privacy.

form_enthusiast About 1 month ago

3

💡 Feature Request

New Field: Chip Input

Chip input support would be great, here is an example: https://v3.primevue.org/chips/ Useful if we need a list of information from the user submitting the form e.g. a list of urls, websites, usernames or other types of info suitable for this kind of list input which cleanly separates each item. Making it great for automation, as well as being quite flexible with the amount of items the user can input while keeping the form simple. Would be ideal if validation could be done during the input of each item also, rather than on form submission.

form_enthusiast About 1 month ago

1

💡 Feature Request

Analytics Opt-Out Query Param for Testing & Uptime Monitoring

It would be great if there was support a query parameter we can add to urls for testing/debugging that will prevent those visits from being included in the from analytics. E.g. /form/hello-world-123?testing=true This way, our own visits for testing purposes could be excluded from analytics, while also making it possible to set up uptime monitoring to check the forms periodically without impacting the analytics data.

form_enthusiast About 1 month ago

2

💡 Feature Request