Whether you’re talking web apps or desktop apps, disabled means there is something easy the user can do to make the control responsive, generally something in the current window. Getting one’s permissions changed by an admin does not count as easy. Therefore, use a plain-text look (black text on a neutral background, avoid using a frame) if the user doesn’t have rights to edit the field. In contrast, use disabled (gray text on a neutral background, include the frame) if the field becomes editable on record status change, especially if the user can do something in the same window to immediately change the status.
However, you need to be careful with disabling fields because the disabled look by design encourages users to skip over the control. Sometimes users will take disabled to mean “not applicable”; that is, not only is the field not currently editable, but value it shows is irrelevant and should be disregarded. Sometimes this is correct. For example, the Reasons for Disapproval field can be disabled if the user sets the Authorization to “Approved” –it doesn’t matter what’s in the Reasons for Disapproval field (if anything) because it’s irrelevant.
On the other hand, sometimes the non-editable field is very relevant. For example, suppose the user cannot change the Transfer Protocol field when a data connection is live, but you want process-control users to see and verify the Protocol is the correct value for the conditions. Disabling in that case should be avoided. If the value is relevant to the users’ task in its current state, use a plain-text look, and maybe provide some other hint that the field can be made editable. Generally, users ignoring a relevant field is worse than users not realizing it can become editable.
I’ve everything on disabling versus the alternatives at Controlling Your Controls.
