Avoid report to allow modifications of records in Filemaker Pro 11 - list

I'm building a database that needs to display tables as lists and allow the user to export such lists as Excel spreadsheets.
Creating the reports, showing them as lists and providing the button for exporting as Excel was not a problem, however I noticed that when I show those lists the user can still edit them, hence add/deleting records and modify the content of existing records.
I'd like to find a way to avoid such modifications when visualizing the list, in such a way to be sure the user does not accidentally change data.
Any idea as to how to do this? I'm using Filemaker pro 11
Thanks in advance.

There are a couple of different ways that might be appropriate, depending on your needs:
In layout mode, click on the field, go to the Data tab of the Inspector, and turn off field entry in 'Browse' mode. (You also have the option to turn off field entry in 'Find' mode. And you can select multiple fields at once to make the selection for all of them.) This is appropriate if your users can regularly enter data into these fields but you don't want them to enter data for this particular layout.
In Manage Database, under the field options, turn on Prohibit modification of value during data entry in the Auto-Enter tab. This is appropriate if you will only be changing the value of a field during an import or with a script.
In Manage Security, create a new Privilege Set that is View-Only for that table (or for those fields). This is appropriate when some users should be able to modify the data and other users should not be able to modify the data.
There are other methods, as well, but those are the three most common for limiting user access to data.

Related

Saving all user input data in Django simply?

This is may be an obvious question to a Django expert, but is there a way that I can save all user inputs (clicks through content without having to explicitly save every entry in a table). If this is possible, then how do I access it later?
If I have to create models, like this I can:
#(within a view function)
UserInputs.objects.get_or_create(user=request.user,
selection1=request.POST.get('selection1'),
id=request.POST.get('id')),
thumbs_up=request.POST.get('thumbs_up'),
thumbs_down=request.POST.get('thumbs_down'),
comments=request.POST.get('comments')
)
Is there an easier way to get it done? Because I have lots and lots of different user click inputs and specifying every one like this will really slow down my application.
Is this data by chance saved in one of the sessions tables? Or can we create a custom sessions table to do this?

Perfrom action based on user input without custom dialog in filemaker

I am developing a database solution in Filemaker Pro 16. I have a "customers" and "projects" table.
What I want to achieve is the following:
User clicks on a button
New window appears in which the user selects a customer from a drop down list
New project will be created
New window appears in which the user can enter the project information.
How can I do this. One can think, of course of an additional table in which temporary values are stored. In that case, I can store my customer selection in this table. However, what about concurrency. What if two people are going to add a project at the same time? In that case you would need a temporary values table for each user.
The most straightforward solution would be to directly store the selected customer in a variable. However, I don't think you can do that.
PS: I don't want to use a Custom Dialog. In that case, I think, you cannot add a drop down list.
Hope someone can help!
Use a Popover button for your customer selection.
Place your Drop Down list in the Popover panel, and store the Customer ID in a global field (they are local for each user).
Perform your script and navigate to your project layout upon selection, for instance using an OnObjectModify Script Trigger.

Extend ELMAH to include another viewer hitting a different table

I've been doing a little tweaking of the SQL-side of ELMAH to provide basic logging capabilities to my MVC app.
I changed ELMAH_LogError to test the TYPE field for text sent by my App and, if found, inserts to a different table that i'd created by 'Script As'
It was reasonably easy to simply create a new table because I didn't try to rename any fields. The structure is identical to the original. Any chance this same principle (same structure/different table name) could be (easily) extended to providing a new 'Logger.axd' that would provide viewing of my newly created table?
thx

How to select from a large number of options when completing a form

I am building a web app that allows our field staff to create appointments. This involves creating a record that contains many foreign keys, of which some come from very large tables. For example, the staff will need to select one of potentially thousands of customers.
What's the best way of doing this in Django?
A pop-up box that allows the users to search for customers, gives them the results, the user selects the results, then fills out the main appointment form and then
disappears?
Changing the appointments form to a customer selection page that
then reloads the appointments page with the data in a hidden form? Or
holding the data in some session variables?
Some from of Ajax approach.
A wizard where the flow is: a customer search page, a list of results and they select from results, then a search page for the next option (for example product selection), etc etc
(I'd like to keep it as simple as possible. This is my first Django
project and my first web project for more years than I care to
remember)
ALJ
Imho you should consider some kind of autocomplete fields. I think this results in the best usability for the user. Unfortunately, this always involves Ajax. But if you think that all users have JS turned on this is no problem.
E.g.
django-autocomplete
or what is probably more powerful:
django-ajax-selects
If you do the wizard approach, it will take longer for the user to accomplish the task and makes it harder to change selections.
Edit:
Well with django-ajax-selects you can define how the results should look like. So you can e.g. add the address behind the name.
Quote:
Custom search channels can be written when you need to do a more complex search, check the user's permissions, format the results differently or customize the sort order of the results.
I have done this before by integrating a jQuery autocomplete plugin. But, seeing as this is your first project and your desire to keep it simple, I suppose you could go with the session data option. For instance, you could show a search page where users could search for and select a customer. You could then store the, say, ID of the selected customer object as session data, and use it to pre-populate the corresponding field in the form when displaying the form. That's what I think offhand.

How are write conflicts avoided in django administration?

Suppose there are two (or more) django administrators who have read a database record and then change and save it. There is no database problem, but some administrators are going to be surprised that the record they wrote was overwritten.
Is this issue ever addressed? One way would be to have an explicit "edit in progress" button which sets a flag in the record. If another administrator reads the same record and then clicks his "edit in progress" he will be warned that there is a previous edit in progress. Or a field could be added to the record which is incremented when a record is saved. If the field is different from when the record was read, the administrator is warned that the record has been changed by someone else since he read it.
Is there a native django way of handling this?
The Django admin does not implement any write conflict protection out of the box. It would not be hard to add it yourself. Personally, I would take the "version number field" approach.
Generally this is where you want to read up on your database's transaction-isolation features, because that's why it has them.
If you'd really rather not do that, various patterns exist for doing this at the application layer, but there is no canonical way to do it -- some people set a sort of "last access" timestamp and refuse to allow editing within a certain period after that, others set version numbers, etc., etc.