Auto Enter Modification Timestamp Left Blank When WebDirect Window Closed (1 Comment)

Issue report by Christopher Edwards

Product

FileMaker Server

Version

13.0.4

Operating system version

Mac OS X 10.9.4

Description of the issue

If a user closes a WebDirect browser window without committing a record, the auto enter modification timestamp will be left blank even though the record is modified.

Steps to reproduce the problem

1) Create a database with a Timestamp field, set to auto enter Modification Timestamp and to require a value. I also have this field set to disallow user editing, though that is not technically required to reproduce the issue. Also add at least one other field a user may edit.
2) Host the database on FileMaker Server and access via WebDirect.
3) Change the value of the editable field and, without committing the change, close the browser window.

Expected result

The record is updated with not only the new field value but also the modification timestamp.

Actual result

While the editable field value is updated, the modification timestamp is left blank. Since this field is not user editable, by design, future record edits will fail until an administrator manually populates the field. Note a similar modification account field is correctly updated in the same scenario.

Exact text of any error message(s) that appear

One example (will vary depending on exact circumstances): "ModificationTimestamp" is defined to require a value, but it is not available on this layout. Use another layout to assign a value to this field.

Configuration information

This occurs with all supported browsers. I have not tested with other server configurations.

Workaround

Make the modification timestamp field editable by users. This, however, is less than ideal.

Likewise, if the user correctly commits the record, properly logs out of the WebDirect application, or uses developer-provided quit functionality, the issue does not occur. I would argue, however, users commonly simply close browser windows without regard to the status of their contents (or a system crash or other issue does it for them), and in no case should FileMaker essentially corrupt the record regardless of external circumstances