The problem imErrorFieldDisabled is uncommon; but, when it strikes, it cripples your ability to save into WorkSite.
The Error
The problem is unlikely to go away on its own! When it appears, it’s important to hunt it down and eliminate it. In this article, I describe how to gather details, diagnose the specific problem, and what the short and long term fixes are.
When contributing something to FileSite, if you see an error mentioning imErrorFieldDisabled and AttributeID, or one very similar, there is something wrong with the ‘profile data’ you just tried to use. This might pop up when you drag-and-drop an email, or when you try to save a Word document.
In general terms, FileSite is complaining that a metadata field on your new item is valid but disabled.
The Evidence
The issue can lie in a number of places. The key questions for cornering the culprit are:
- Does the error appear only when contributing to a particular workspace and/or folder, or to a group of workspace/folders, or does it affect all folders?
- Does the error appear only on one user’s machine or is it affecting all users?
- Can one user contribute to the specific folder successfully while a different user still has this problem?
- Does the error appear only when contributing emails, or does it also affect documents?
- Crucial: which AttributeID is it complaining about? Custom1? Custom12?
The Diagnosis
If it happens some times but not others, it’s a problem with the metadata for the workspace or folder you are adding-to.
If this is happening all the time, but only for one user, then it’s likely a problem with something specified in that user’s Email Profile Defaults or Document Profile Defaults.
If it happens for all workspaces and for all users, then some ubiquitous metadata value is disabled
The AttributeID refers to the specific profile field. Here are the most common fields:
- Custom1 (imProfileCustom1) means client
- Custom2 = matter
- Author = author
- Operator = Typist or current user
- Custom29 = practice group
How to fix it
The fix depends on which field is broken.
For users and practice groups, there is no automated process that might break it, so typos in the profile screen or profile defaults are the most likely culprit. Because this is a per-person problem, it’s a localized fix. Check the Outlook FileSite menu’s Document Profile Defaults and Email Profile Defaults, and fix it there in that display.
The billing system export should not be setting active clients or matters to disabled. The fast fix is to request that your WorkSite technical support team re-enable the client and/or matter. This can be done instantly through the Worksite Database Administration tool on the worksite server.
The longer-term fix is to export the active status correctly from the billing system, or to correct it in the billing system if that’s the root problem.
Sanity-checking the Meta-data
To confirm whether a particular matter is enabled or disabled (or a user ID, or client, or practice group), there is an easy do-it-yourself approach. This example walks you through a client validation, but the same approach works for author and practice group. For matter, fill out both client and matter.
- Do a document search (see the toolbar button that’s lit in this picture).
- In the appropriate field, fill in the ID you want to check (in this case it’s client number 1240). You can find the client number in the name of the workspace, and at the end of each folder name.
- Click the … button to the right of that field. The popup Selector window should have that entry selected (as shown here with client 1240).
- The Enable Flag column tells you whether it is Enabled.
- In this example, this client is not enabled, and so you will not be able to contribute successfully to any workspace associated with this client.
One thought on “Metadata misfire: imErrorFieldDisabled | FileSite close-up”