try the following autoentry:
field myModTime, autoenter modification time;
your autoenter timestamp field:
Let(trigger = myModTime ; If(Get(AccountName) = "Admin" ; Self ; Get(CurrentHostTimestamp)))
siplus has given you an answer that matches the question you asked. However, what is your actual use case? Are you wanting to suppress all modification timestamps whenever anyone logs in under the Admin account (which you should change; there's a vulnerability associated with the account name of "Admin")? Or are you really wanting to avoid the modification timestamp being damaged when you perform some sort of routine maintenance (like importing during a version migration)? Here's why I ask: Oftentimes, we'll be asked to "fix" something in the data. If you're relying on the modification timestamp for some sort of scripting, you could inadvertently suppress an update that should happen.
If that's not what you want, you can create a global field and use that in the calculation siplus provided:
trigger = myModTime ;
Case ( not IsEmpty ( globalTable::suppresModTimestamp ) ; Self ; Get ( CurrentHostTimestamp ))
Then whenever you want to prevent timestamp updates, you put a "1" or "Y" or whatever in suppressModTimestamp (a checkbox makes it convenient). You can do this via scripting as part of any automated updates. That way, you pick and choose when the timestamp doesn't fire, instead of always suppressing every update based on privilege set or account.
Something else to consider.
Taking Mike's "Why?" question a little further, consider the usefulness (uselessness?) of the modification timestamp anyway. What does it tell you? For example:
• If you cut the contents of a field, then without leaving the field paste them back again, the field value has not changed but nevertheless the modTS changes.
• If you do the same thing again, but this time click outside the field between the two actions, the modTS changes twice, once when you cut, once when you paste.
In each case the modTS has told you nothing useful, only that someone did something somewhere in this record.
Why not consider setting up an audit trail instead.
Sometimes the real useful information is to know that a record has NOT changed after a certain instant in time, you don't care about what has changed (because if it did change, you're going to restore the whole record from a backup copy, for example).
An audit log will tell you that too.