WebDirect changes in the latest security-inspired revision greatly limited what can be passed via URL for record or layout navigation.
It sounds like a found set is stumping the process. Get(RecordNumber) is entirely dependant on the found set, as is the Go to Record if using the Record Number. Record number can also depend on the sorting of the found set at the time the number is captured, and may not match sorting at the time it is reused.
One workaround: if you have a Record ID field (or add one as a stored calc field), using that field value in the email and advising users to search on that Record ID? Admittedly, not as intuitive as a clickable link, but unlikely to be broken in revisions, and reliable once the users have a couple of minutes training or brief instructions within the email.
Thanks, Stephen, but that doesn't work.
I do have a record ID field as a stored calculation - I put this into every database I build, every table. Very useful for all kinds of reasons, including this one.
but if I check the Get(RecordID) value in the Data Viewer or by making the calc field visible on a layout and then check the URL it absolutely does NOT seek that value when the URL goes looking for RecordNumber,
Moreover, what you wrote about the found set is also negated by the reality: I have 53 records in the found set and the browser is seeking record #57. How can that be?
I admit that I have been able to circumvent the problem by telling the user what number to search for when they get to the Web Direct page, but it seems awkward and unnecessary to do this if the browser can simply be instructed to grab the correct record.
I know it can be done with CWP and a simple PHP call. I just thought it could be done in Web Direct with ease but apparently it can't.
I wasn't suggesting that you pass the Record ID via URL, but with instructions for a manual search. Like I said, not as neat as a URL to click, but not likely to break with any future rev.
As I indicated regarding the found set, if you only have 53 records, your URL doesn't know that; it just knows it cannot get beyond 53. Why is there a partial found set? Was the database closed before hosting with a found set? If you could get the database to open with Show All as the found set (not in the opening script, which won't override the URL) you may be able to get the record number in the URL to work.
Try taking the file off-line, adding a Show All to any closing script, or create a closing script which Shows all records, close the file so it has All Records in the found set when last closed unhosted, then rehost the file. Maybe it will then open with All records by default, your record number URL might work.
Basically, I adopted your approach about giving the user instructions for perform their own manual search. What I don't like about this is that it doesn't prevent someone from doing a search for a differnent field value and thereby seeing something they should never see, namely, someone else's record. Of course, I could build in a way to validate the identity of the user but that sort of defeats the purpose of making it simple for someone to access a web page and click a radio button to answer a question.
What you say about the URL not knowing that it can't get beyond 53 doesn't make sense to me, because if it knew that, then it would not be sending the user on a query for record 57. The question I was really asking was: "where does it get the number 57 in the first place?" ( I know one possible answer: from a Heinz ketchup bottle, of course. :-)
The found set is supposed to be irrelevant, The person using a web browser to go to a databaase has no way of knowing what the found set happens to be for any of the 100+ FMP users who have regular use of the database. Imagine this scenario: there are 100 customer service reps all working on the same database and their found sets of records could vary from 1-100,000 at any given moment. A script is used to send an email to a customer with a URL that the customer can use to view some details of an order, or agree to a price quotation by simpling clicking a radio button with YES and NO as the options. It should be simple and fast to generate the email and for the recipient to click a link that goes directly to the particular record.
i can't imagine that I am the only person with a need like this, but if it really can't be done in Web Direct,then there is no reason to not just build it in CWP and forget about the FMP/WD constraints.
Of course, I could build in a way to validate the identity of the user but that sort of defeats the purpose of making it simple for someone to access a web page and click a radio button to answer a question.
Validating the user with a login process whereby the database opens using a default account which is scripted to immediately force a relogin would allow you to use RLA -- Record Level Access, so they can only see those records to which they have been assigned. This would require uses to know and use individual file credentials (Account Names/Passwords).
What you say about the URL not knowing that it can't get beyond 53 doesn't make sense to me, because if it knew that, then it would not be sending the user on a query for record 57.
Exactly my point, the URL doesn't know it cannot get to #57 until it tries and fails. It's a URL, not a script.
The found set is supposed to be irrelevant, The person using a web browser to go to a databaase has no way of knowing what the found set happens to be for any of the 100+ FMP users who have regular use of the database.
But the found set is never irrelevant to the current record number; the found set is the context in which the URL tries to execute going to the specified record number (which doesn't match the Record ID). That's why I suggested that the file be closed unhosted with all records shown, in the hopes it will then open that way when hosted.
...if it really can't be done in Web Direct,then there is no reason to not just build it in CWP and forget about the FMP/WD constraints.
The only reason I can think of is that, if it did work in WD, that would be a lot simpler than building a CWP solution. If you are up for CWP, a bunch of better options open up for you. No disagreement with you there.
From: http://help.filemaker.com/app/answers/detail/a_id/13183 for the FMServer 13.0v2 update:
5.2. User interaction in FileMaker WebDirect solutions
The capability to specify URL parameters or to bookmark specific locations within FileMaker WebDirect solutions has been removed for security reasons. You now specify only a filename in the URL to open that file.
You are certainly not the only person who is going to have problems delivering the solution you'd like to because of this change. However, I don't think there is a straightforward solution except for PHP and custom web publishing.
Possible Web Direct compliant solutions include setting up a users table and a startup script that can take the user to a 'dashboard' showing them all of their appropriate records (thus you do the search for them), or, if you don't want that many user accounts, then a generic FileMaker authentication and a different sort of users table that does a it's own version of user identification and takes them to the correct record, even if that process is as simple as entering the "ticket ID" from your email.
Certainly less elegant, but functional.
-- Drew Tenenholz
Thanks to you both. I get it. Basically, I was pushing the envelope too far. Pity.
Actually you were just trying to use the envelope they gave you, but then FMI took it away so nobody could misuse it.
(It can a real shock when functionality is removed, but security increasingly trumps all else.)