Hi Lars,
There aren’t really users in Tap Forms. It’s not a client/server database application like some other database engines. It’s designed to let you sync data from one device to another using your own sync credentials, whether that by iCloud, IBM Cloudant, or Apache CouchDB.
If you wanted to sync with different users, you could setup a CouchDB database:
https://www.tapforms.com/help-mac/5.3/en/topic/apache
… and setup different users there to sync with a specific document. You could enable access controls to prevent anyone from modifying the database via the Tap Forms application who shouldn’t. But it wouldn’t prevent them from editing the database file directly and having that information sync to other users copies of that document in Tap Forms.
Thanks,
Brendan
Hallo Brandan,
my proposal to split things up between work-stuff and editing-stuff is totally devoted to the experiences with my coworkers. Although i am a aware TF is a personal product, i thought it would be nice to have something like another Database “NinoxDB”, which spilts up those areas nicely and prevents the “digitally challenged” (no insult meant) from doing the unexpected.
I have added some screenshots that make it clearer.
Regards,
Alexander
Attachments:
You must be
logged in to view attached files.
Hi James,
Thanks for the feature requests.
When you double-click on a child form, the last selected layout of the child form is already selected for you. The form that’s selected corresponds to the child table’s form. So that’s already set for you. Perhaps you were confusing form and layout :)
Required fields is actually more complicated than it sounds. It would require a fundamental shift in the way data is entered into Tap Forms. For example, when you visit a website to fill out a form, there’s always a submit button somewhere on the form that you click on to send the form. At that moment it does validation and then returns a page with the missing fields marked. So Tap Forms would probably need to adopt something similar. You would need to have two modes of operation; 1. Edit and 2. Save. That would also need to apply to 3 different views. The Default Layout view, all your custom layouts, and the multi-column list view. You would also have to be prevented from moving to another form if you didn’t first save and/or deal with the form you were currently editing (from whichever view). Alternatively I could just mark required fields with a red border, but not actually enforce anything. It would be more of a visual indicator letting you know which fields you’re “supposed” to fill in.
The Default Layout doesn’t really need to be hidden I don’t think because as long as you have a custom layout, Tap Forms will always display the last selected layout. So just never select the Default Layout if you never want to use it.
I’m working on the option to restrict the Pick Lists to only the set of values you’ve specified.
So I guess with the Locked fields option, how would you propose you edit them if you needed to change their value? Or is it a once set, tough luck sort of thing? :)
Thanks!
Brendan
Ivan,
In order to provide this kind of ability, Tap Forms would have to fundamentally change the way viewing and editing the form’s contents behave. I have been thinking about making this change, but I don’t know how people would react to it. What I would need to do is have an Edit/Save button at the record level. So when you view a record, you would not be able to make any changes to it unless you clicked the edit button. Then when you made your changes, you would click the Save button to save the changes for that record. At that point, Tap Forms would scan for incomplete values and mark the fields (probably with a red border or something) telling the user they’ve missed some information. So more like a website form that you fill out rather than a desktop app.
But then this becomes problematic for the multi-column list view where you can simply click on a cell and start typing to change its value. I would have to have a toggle up there for that too.
So it’s a bit of a complicated thing for me to build because I’m not entirely sure what the right user experience should be to support required fields.
One possibility is to simply mark every required field with some indicator (like a * or something) and that’s it, but that wouldn’t prevent you from leaving out the data from a required field.
Now, after re-reading your question, you were asking about Unique fields. That’s entirely altogether different. Sorry about the message above, but it’s a good discussion to have regardless. I guess the only thing with unique fields is that every time you save a value I have to scan all the other records to make sure you’ve never used that value before. I’ll think about that.
Thanks,
Brendan
After using the trial version for a few days I have decided to wait a little buying TapForms. Here are some ‘issues’:
1) There were too many ‘unexpected quits’.
2) I could not get the formatting of the note field right.
3) The form editing icon acted strange and sometimes prevented me from using the form. I had to restart the app first.
4) The database file is not in a user-chosen location. I have an SSD drive for the system and the apps and have my data on a data disk. That is not possible with TapForms.
The software looks good and is very promising, but a database app should be full proof. So hopefully a future version will solve these issues.
Hi Bert,
Thanks for the feedback.
1. The biggest thing to get right is the File Encoding setting. Tap Forms needs to be told what the File Encoding is of the file itself. Once that’s right, importing files usually succeeds without issue.
2. I’m testing out a new sync system using the Couchbase Mobile database engine. If all goes well with that, it will mean the end of having to worry about syncing. It should just happen automatically whenever you make changes to your database without user intervention.
3. Reset Sync will do what you did manually. It deletes the .tfs and .tfx files for you. If you’ve added and deleted and added and deleted a lot of records, then your database file will get bloated. Running the Vacuum command will compact the database.
4. Hopefully the Couchbase system will prevent the hang from happening. It’s due to the database being locked while it’s being written to during a sync operation. If you try and do something while the status bar shows that rows are being updated, then you’ll get locked out until the sync completes.
5. This is already there. Tap on the action menu button on the iPhone version when viewing a record and you’ll see the pencil button to toggle record editing.
6. Understood. This is something that I need to investigate further. I’ve done some testing with this and it does update for me, but for some people it doesn’t. Not quite sure why yet.
7. Understood. Again, hopefully the new sync system with Couchbase will make this much better.
8. Ya, I’ve seen that odd font too. I think it’s when the note field doesn’t have a font defined for it yet.
Thanks,
Brendan
Thanks for the feature request Michael.
Even though the iOS version has this feature, it’s not super secure for preventing form editing since the TFF file itself contains the passcode and could easily be changed or removed. It was really just a way of preventing general users from editing the forms, but for anything commercial, it’d have to be way more robust than that with probably a unique data format, not so easily inspected.
I would also find use in being able to distribute “Read Only” versions of certain TapForms databases. I see the option of developing a stand-alone database as an potential extension of this. However that seems to get in to the questions of how you cover for a return on investment (do you charge royalties on the folks who want to charge their users for “buying” their stand alone databases or not?) and how you mitigate against tech support issues when folks start complaining that their standalone database is not working well because your TapForms app is sloppy or has problems (when the truth really is that their distributor built a crappy standalone database). Of course, I may just be overthinking the issues here.
Anyway, my vote would certainly be to be able to create locked databases that require TapForms or TapForms Lite but prevent users from being able to add/delete/change the records in them.
—
JJW
First — Tap Forms is a GREAT APP! I am finding more and more uses for it, and I really appreciate the hard work that is going in to it. Thanks!
I would like to be able to HIDE fields (of any type) from showing on the view of a record, especially intermediate calculation fields.
I would like to be able to LOCK records from further editing, especially to prevent accidentally overwriting what should be a “hard stored” database record.
Finally, I would like to be able to use GLOBAL variables in calculations. A simple example is to create a calculation field that shows a conversion patm = ppsi/pconvert, where ppsi is the field where I enter a value, patm is the field that is automatically updated, and pconvert is a defined global.
—
JJW
