I'm tempted to say this is WFA 3.1P1 problem but maybe it isn't. Can anyone see anything wrong with this attempt to set a UI field ($dataType) to Type Enum, provide two choices (Prod or Test) then set the default value to Test. Notice in below that the Default Value box is red and will only clear and let me [OK] this without a default value. Lock Values, Mandatory, each enum choice on line or separated by commas, upper/lower case all seem to make no difference. The only thing that seems different to me is I upgraded to 3.1P1 a couple of days ago.
I have another UI enum field in this workflow that did not seem to have this problem ... i.e.; it had a default value that was accepted. I took out the default value, saved the workflow, then went back in to try and add-back the Default Value and it now behaves the same way.
I started development of this workflow in WFA 3.0P1 at which time I had added the other UI Enum with a default vallue. But now attempts to add a default value with 3.1P1 are failing.
Or does someone else see a problem.
This is easy to recreate w/WFA 3.1P1 : 1) create a workflow, 2) add a constant TEST_ENUM with $testEnum as it's value, 3) Go to User Inputs tab and attempt to set $testEnum to an Enum with a default value
I just tried it on my installation at 188.8.131.52.0-2879153, and had the same problem when I opened up an existing workflow that had an ENUM type, with a default value already set. I believe I built this workflow before I upgraded to 3.1.
I just noticed an additional piece of data on this problem. I noticed that the 'Default Value' field doesn't turn red until you type the 2nd character. So I chnaged my Enum list values to be 1-character in length, like: P for Prod and T for Test and made T for Test my 'Default VAlue'. All works fine in that case. Not an acceptable workaround but ... fyi/fwiw.
For now I'll declare this an OS X Safari browser related happening. From a test this morning (after also doing an uninstall/reinstall and DB-restore sequence) I am able to re-produce the problem with Safari (which is not a supported browser) but it works fine with Chrome.
- Chrome Version 46.0.2490.80 (64-bit)
- Safari 9.0.1
Thanks David for your update.
Just want to mention that Safari is not a supported browser.
But it is good to hear that things have been working fine in Safari barring this issue.
The supported browsers are Chrome, IE and Mozilla.
Support matrix link is available here:
Safari is NOT a supported browser. If it works fine, good. If it doesn't then WFA can't be held accountable.
Here is another issue with WFA3.1P1 and enum user inputs that I encounter in Chrome. I'm wondering is this is easily re-creatable by others in other browsers.
1) Create a user input variable, set it's type to enum
2) For Enum Values enter: abc,def,ghi
3) For Default Value enter: def
4) Preview and see correct behaviour
4) Change the Enum Values: to one-per-line as in abc<cr>def<cr>ghi
5) Change nothing else and click OK
6) Preview and see correct behavior
7) Re-open the uer input variable
😎 Notice immediately that the Default Value is highlighted in red and you must clear it to contine or [OK] out
9) Alternatively, leave 'def' as default and open Enum Values: and add a comma to the end of lines 1 and 2 like: abc,<cr>def,<cr>ghi
10) Now you will be able to enter a Default value of abc -or- def -or- ghi
I thought enum values could be comma-separated-list of one-per-line. This can be worked around by temporarily adding the ","s, then entering your default value, then removing the ","s.
Anyone else seeing this? This is Chrome 47.0.2526.80 (64-bit) on Mac OS X 10.10.5
This BURT is still open in 4.0RC1. BURT number is 974827.
However there is a workaround possible as has been suggested:
This can be worked around by temporarily adding the ","s, then entering your default value, then removing the ","s.
If you want it to be fixed, you can log a case with 4.0RC1 by calling up customer support.