JotForm is a free online form builder which helps you create online forms without writing a single line of code. No sign-up required.
We believe that if one user has a question, there could be more users who may have the same question. This is why many of our support forum threads are public and available to be searched and viewed. If you’d like help immediately, feel free to search for a similar question, or submit your question or concern.
How can I prevent more than one weekly submission on a specific field of a form?Asked by eyugame on May 15, 2016 at 10:35 PM
i have a form that provides my team with a variety of different response fields. my question is one of those response fields is for them to submit as a time ticket for pay, is it possible to prevent them from filling it out twice in a specific time range, say once a week without causing problems for them on the other parts of the form. Each team member has an assigned number which is required for their time ticket, but it is also required for the other parts of the form, my team has a high turnover rate due to being voluteers, so its not feasible to create password fields or conditional logic to stop someone from submitting just the time ticket portion of the form. they must be able to continue to submit the other sections of the form as many times during the week as they possibly need to.
I am not quite sure if that is possible. I believe with the current features you cannot prevent one specific field to only be limited to one submission per week. You could limit your users based on a specific question as mentioned in this guide: https://www.jotform.com/help/223-How-to-set-Form-Limits-Based-on-a-Unique-Question. But that will prevent the user to submit the form as a whole, and it does not refresh or restart on a weekly basis, unless of course you manually changed the settings of the form.
This is somehow possible if you'll use your form's full source code, inject a custom script that will check your users current submission data via API and disable the said specific field. However, you'll need to embed the form on a web server and have some knowledge in programming (or you can hire a developer) for the custom script. Here's a more detailed step:
1. First, get your form's full source code.
2. Create or hire a developer for the custom script.
3. Use API to check if the user has an existing submission data specific on that field. If he/she has, then disable the specific field. Here's our API documentation: http://api.jotform.com/docs/
4. The tricky part is the refresh or restart of this limitation on a weekly basis, you'll probably need a database to temporary store the data then compare the dates or week. This will probably need a cron job I believe.
I hope that helps.
now i have another question, if its against the terms to create a password field, why is it an option? Aside from that, it would be a password we set for the form, not asking our team to use any of their personal security information.
I believe we do NOT allow password fields at all. May we know where you saw that it is an option? If you are referring to old threads, there might be some support team members that have suggested it before, but due to an event that happened last 2011, our management have been strict on implementing anti-Phishing protocols in our system. We have an anti-Phishing detector system and we also have manual reviewers. This happened because the US government have suspended our domain due to real phishers using our forms last 2011, you can check my manager's post and explanation in these threads:
Password fields are absolutely NOT allowed. These mimics a phishing page and is collecting sensitive information. Regardless if the password is generated by your organization or anything else, the password field will be detected by our anti-Phishing detector AND our manual reviewers as a violation to our terms without any exception. There are some information like SSN that can be collected but ONLY if it passes the criteria and requirements that we have.
Also, JotForm was NOT designed to act as a log in page or a way for collecting log in credentials. This is because such information needs to be stored in an encrypted database with administration access. JotForm does not offer those services or methods.
I hope that helps.
i understand what you are saying, i'm not sure you understand what i am saying. so i will try to explain it differently.
i have a form that is used by our staff, as well as our clients.
the form is NOT, has not been, nor will ever be used as a login page.
the form is not, has not been, nor will ever be used to gather any type of sensitive information.
the "Password" would have nothing to do with collecting any type of login information, it is in essence conditional formatting that will only show a certain part of the form if someone has the predefined "password" we have created to show the part of the form, the form does not get linked to any part of our business outside of the form its self. The "password" is literally to make sure unauthorized access to a specific part of the form itself is not accidentally granted for a report that is only for our staff, it is not a login password, its not asking for a password for any type of account, so i guess what i am saying is i am calling it a password, but its not honestly a password and would not be in place to deny access to any secure,or sensitive information, its literally to keep part of our form from being filled out accidentally by one of our clients.
if this is still considered against the rules, then i will speak with out team about separating that part of the form into a new form, i understand rules are rules, while i don't really understand what the problem would be with this specific situation of implimentation i guess it is what it is.
Based on your explanation, I understand that what you are referring to is an access code that will conditionally give the user access to parts of your form if they entered the correct code. That type of functionality is certainly allowed in jotform. However, I would advise against labeling that field as "password". I would suggest naming it as an "access code" or "access key" instead to avoid confusion.
If you need further assistance, please let us know.