Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
12 REPLIES 12
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I just tried it on my installation at 3.1.0.0.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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
FWIW, versions:
- WFA-3.1P1
- Chrome Version 46.0.2490.80 (64-bit)
- Safari 9.0.1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Safari is NOT a supported browser. If it works fine, good. If it doesn't then WFA can't be held accountable.
sinhaa
If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Will check this and log an issue if it is reproducible.
Regards
Abhi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Korns,
We are able to reproduce this issue
We filed a bug . will keep you posted.
Regards,
Sundar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Sundar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
did we get any update on this one?
encountered the same with WFA 3.1.0.0.2P2 and IE and FF
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Regards
Abhi
