Bug in WFA 3.1RC1 command "Create CIFS Share"

[SCOTT_LINDLEY]

There is a bug in the Certified Command "Create CIFS Share" in WFA 3.1RC1 that was not present in previous versions. The bug manifests itself as a failure in the command when you create a share with a comment and the comment contains whitespace. The fix is simple, though WFA is balking at letting me overwrite a "Certified" command - I'll figure that one out shortly I hope as I don't want to have to reconnect a new command to all the workflows we care about, even if that's a short list. Anyway, the fix is to change the code fragment that reads:

if ($Comment)
{
    $command += " -Comment " + $Comment
}

to this:

if ($Comment)
{
    $Comment = "'" + $Comment + "'"
    $command += " -Comment " + $Comment
}

Enjoy!

    Scott

[sinhaa]

Hi Scott,

     This is not a bug, but only that you are expecting a different behaviour than what the command designer had in mind. Who is correct? Its a matter of opinion. Let me explain you.

The problem you are mentioning comes if I have multi word comment i.e. words separated by a space ex : Hello World

You want to provide the multi word comment without giving any quotes. If you do this the command fails.

So now you want to modify the code adding quotes into the Comemnt string. Seems okay but lets see the other side.

The WFA command designer had other ideas:

He thinks that if a multi-word comment is to be provided, the User needs to provide this argument in double-quotes or single-quotes like : "Hello World" . Else it will take Hello as the only argument to parameter Comment and since won't be able to find any parameter for the World, it fails.

This is not an incorrect expectation. ONTAP CLI expects this, ZAPI expects this, ONTAP PSTK expects this.

f3270-208-238-239-240-241:: > cifs share create -share-name ab_sinha -path / -share-properties oplocks,browsable,changenotify -comment Hello world

Error: "world" was not expected. Please specify -fieldname first.

f3270-208-238-239-240-241:: > cifs share create -share-name ab_sinha -path / -share-properties oplocks,browsable,changenotify -comment "Hello world"

f3270-208-238-239-240-241:: >

Thats why to be on the same line as others, this WFA command should also behave similar.

WFA command is only trying to keep it consistent across all interfaces.

Also if we change the code as per your fix and divert from the regular common behaviour, I migth end up having unexpected behaviour for some othe users in other cases. Example: If I give "Hello World" i.e. doubles quoted values for Comment the result will end up adding quotes also as a part of my comment.

Instead of my comment being Hello World , it will become "Hello World"

The quotes also becomes a part of the comment and I'm thinking it won't. I don't think this would be right.

So if you want to pass multi-word comment, Kindly keep them in double quotes as in the 2nd image above. The WFA command will work just fine.

sinhaa

[sinhaa]

Hi Scott,

            Relooking at your topic and I think your issue can be solved without modifying the command code and you don't need to add quotes while providing the multi-word comment in your workflow.

Make this change at your workflow:

For Parameter comment, give input as: "\"" + $Comment + "\""

 sinhaa

[SCOTT_LINDLEY]

Thanks for the suggestion. While that will likely work, I can't expect my team to remember to place this construct around comments with whitespace. It's not something that I can expect them to remember, nor should they have to. The code should compensate for reasonable inputs such as this, and now it does. These sorts of allowances should be present in all commands IMHO.

    Scott

[sinhaa]

I understand your point Scott. But fixing the command code it would make it incorrect for some other users. That's why I suggest you fix it at the worklow as I said in my 2nd post. This way it should work good for all.

sinhaa

[JoelEdstrom]

-- Edited message as I see what Scott's getting at once I took a second look at things.

This might be bit of a change for any area that accepts comments or whitespace in ONTAP.  Previous to WFA 3.1 it looks like WFA took care of wrapping multi-word strings submitted to a variable via User Input in single/double quotes on your behalf.  This doesn't seem to be the default behavior anymore...

[JoelEdstrom]

Sinhaa - 

Should we expect this behavior applied to creating CIFS share comments to eventually reach all items that can take comments?  The same behavior is seen when trying to add a comment with whitespace for an SVM but is *not* seen with modifying volume comments.  

Granted, there aren't a lot of locations other than comments where we'd need whitespace in a string but it'd be nice to get clarification on the long-term goal here.  Trying to remember which commands need quotes, or your workaround with the MVEL wrapping in the command(s), is going to be difficult.

[sinhaa]

Hi Joel,

@ Should we expect this behavior applied to creating CIFS share comments to eventually reach all items that can take comments?

-----

Yes, you should expect this and so would I and rightly so.

@  The same behavior is seen when trying to add a comment with whitespace for an SVM but is *not* seen with modifying volume comments.  

-----

Ahh right.. Modify commands have a different route in code and hence behave differently. I can explain that, but let's not go there. I completely accept that for an end customer all WFA commands should behave one way. It doesn't so I can't justify it. 

@ Granted, there aren't a lot of locations other than comments where we'd need whitespace in a string but it'd be nice to get clarification on the long-term goal here.  Trying to remember which commands need quotes, or your workaround with the MVEL wrapping in the command(s), is going to be difficult.

----

I'll log a bug for it. The following should be the behaviour for ALL WFA commands.

1. The command code should take care of multi-word comments. User need not worry about adding quotes during command Test or at workflow.

2. If user provides a comments within quotes, the quotes shouldn't become the part of the comment. It does now for Modify commands.

3. So for all the users who want to provide comments with or without quotes, the WFA command should be behave consistent.

sinhaa

[JoelEdstrom]

Sinhaa -

Thank you for all of your help with this; it's greatly appeciated.