Hey all. So, I don't know why this would be true, but after hours of testing, here's what I found. Any ideas why?

Scenario: many passwords (using access privileges) including one "nopassword" that has no filemaker abilities, but will work for limited browse/edit via the web by having users set their own passwords (using field name matching, fairly standard stuff). Now, I deselected any options for this password EXCEPT for limited browse and edit (by forcing a current status by those who come in through a certain entrance to the site). It works fine, but one of the first pages is driven entirely by inline actions:

[fmp-inlineaction: -db=mydb.fp5, -layout=forcedlayout, user={currenttoken:2}, -find}

[fmp-currentaction] (just to check to see if the inline is processed) [/fmp-inlineaction]

Now, realize that the code above is completely abbreviated. But, if I can get the -currentaction to actually say something, I'll know the inline is processing. Entering the site with the "no password," no dice. However, then I went back to access privileges and selected every box for the password on the front "access privileges" screen, AND I kept the limited search/edit features. And now it works completely fine. I mean, I guess I opened up the password to extra functions (such as delete, export, etc), but for the most part, users will never get a chance to take advantage of those features. But, why would the inline require this level of access to run correctly? I didn't change any browse/edit privileges from the first time to the successful time.

Any takers?

Bevin

Anything on the Layout "forcedlayout" causing any problems?

Garry

i don't think so...it's just a layout that has all the fields on it.

You posted: >

"[fmp-inlineaction: -db=mydb.fp5, -layout=forcedlayout, user={currenttoken:2}, -find}

[fmp-currentaction] (just to check to see if the inline is processed) [/fmp-inlineaction]"

Let me assume (ass - u - me) that you have copied and pasted this code. Ergo,

-find}

should probably read

-find]

We had an inline action that worked fine with our internal testing, but when it was put onto out clients site the inline action broke.

We were using same HTML, databases, etc.

We were finally able to duplicate the problem by accessing out test system externally and fixed it by changing the access privileges.

We found that we needed the Export Records privilege in addition to browse records on our no password login.

Stephen