Expand my Community achievements bar.

Join us for our Coffee Break Sweepstakes on July 16th! Come ask your questions or share your use cases on Creative Briefs for a chance to win a piece of Workfront swag!

Disable Inline Editing at Column Level

Avatar

Level 10

9/5/19

I'd like the ability to simply set a flag light "inlinediting=no" when I want to turn-off inline editing on a specific column of information.


We had to work-around some limitations in Workfront that tied the value of one field to another field so closely that I want to make sure that dependency kicks-off any time someone changes data in the first field (such as doing mock cascading fields). Since this dependency doesn't carry over into to reports I want to force users back to the custom form to make changes. To do THAT I need to be able to disable inline editing for that field.


Doing it by leaping into text mode and doing some calculation on the value to stop it from being editable is very kludgy and non-intuitive.

3 Comments

Avatar

Level 5

9/6/19

I can’t see much value in this.


What about adding a calculated field that replicates the value instead? Then it isn’t editable in line and you don’t need text mode. ;)


Cheers,

Imi

Avatar

Level 10

9/7/19

Imre,


Well for one, that means creating another field, which isn't much better than hacking-away at text mode. I already have too many fields of this sort to work around problems. ;-)


But if we really wanted to get fancy, WF could just offer a little checkbox that says "disable inline editing." They could even grey-out the selector to indicate the field will NOT be inline-editable because of all the usual reasons; this would be great for those new to the system.

Avatar

Level 2

3/25/24

I realize I'm jumping into this conversation a tad bit late (5 years late!), but there is a simple solution to this. I will still reply here for any future viewers.

In text mode, simply add the line, "makeFieldEditable=false" to the code, and it will disable inline editing on any column where this code is applied. 

There are a number of use cases and advantages this can bring. Sometimes you are building a report or view where you don't want to folks to edit the data or at least not to edit it directly through the report or view such as if the report or view is designed for the purpose of displaying data but not changing the data. Sometimes Workfront can be difficult to work with in terms of who has edit permissions on certain fields, and this is one way to curate the user experience, at least with respect to this report or view.

Creating a custom calculated field or modifying the view to perform a calculation on the column (e.g., "CONCAT({My Field})" does technically work. However, they can be a bit clunky, and I have found the "makeFieldEditable" parameter much cleaner as it was designed for that purpose.