Colons in names - it shouldn't be possible but I've found some

Hi,

Today I helped a user who had created a ton of items via WS where a colon got into the French name (in DTreeMultilingual, not DTree) where I had to rename the French to get rid of the colon (:) and replace it with '_'. OK, that's done. I however further noticed we have about 900 items in our system (most in the recycle bin but a few in people's personal WS) where there is a colon in the name. This appears mostly for email messages but also regular documents.

What has me perplexed is that any node creation event goes through llNode.NodeAlloc() which almost always calls LLNode.ChecknewItem() on the LLNode object for the parent which in turn ultimately calls $LLIAPI.NodeUtil,Checkname() not just on the System default language, but on any additional metadata language passed in. And the only condition of $LLIAPI.NodeUtil.Checkname() (which is called by the former), is that the name not contain a colon.

The only way past this logic is either a) the parent LLNode object bypasses the check (you could make an argument for email folders, maybe) or if instead of a parent ID, you are passed in a dapiCtx, in which case, the check is bypassed altogether.

I can't believe that either is happening, and the cases I've encountered are for objects created in a folder in a Personal WS, and objects created in the Enterprise WS by web services (both should call the default NodeAlloc method with a proper parent passed in).

Are there any scenarios I've missed? is this perhaps a known bug in CS 10.0 U 2016-06?

Thanks in advance

-Hugh Ferguson

Find more posts tagged with

Comments

HFCDev

I've reproduced the use case that produces this. It's not actually a colon but a full-width colon (a Microsoft character) - Unicode 0xFF1a. We successfully reproduced this using the drag and drop feature of Enterprise Connect 10.5.2 into CS 10.0 U2016-06 and SQL Server 2012. It looks like that when the string comes in, it is encoded and when it gets stored in the db, you can see the sequence of bytes when you convert the name field to Varbinary (SQL Server). However, when you read the item back out as in any DAPI call, it reinterprets the full-width colon as a regular colon. I'm guessing that this happens at the drop-in level.

I haven't attempted to reproduce in CS 16 yet, but I'd be curious if others could.

Either way, if it's reproducible there, then this is one for the Ent Connect team to patch.

-Hugh

HFCDev

The mystery deepens. In some cases, CS allows the full-width colon, but in others, after it gets entered, it renders the item un-movable.

-Hugh

AKropp

Hi Hugh,

I’ve sent your discovery over to a colleague of mine who deals with EC so he can have a closer look. I didn’t see anything logged in our bug tracker, but if it already exists maybe he can find it. Else we can get it logged.

Cheers,

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Wednesday, October 26, 2016 3:43 PM
To: eLink Recipient
Subject: Colons in names - it shouldn't be possible but I've found some

Colons in names - it shouldn't be possible but I've found some

Posted by Ferguson, Hugh On 10/26/2016 03:39 PM

I haven't attempted to reproduce in CS 16 yet, but I'd be curious if others could.

Either way, if it's reproducible there, then this is one for the Ent Connect team to patch.

-Hugh

[To post a comment, use the normal reply function]
Topic:	Colons in names - it shouldn't be possible but I've found some
Forum:	Content Server Development Forum
Content Server:	Knowledge Center CS16

Jim Hewitt

Hello,

I quickly tried to reproduce this issue with the 'Fullwidth Colon' (U+FF1A)'. I was able to add it into Content Server 10.5 and Content Server 16 both with Enterprise Connect and HTML5 drag and drop. However I haven't had any issues reading it back out, or moving the object in Content Server.

What error message gets presented back to you/the user when you attempt to perform these operations?

HFCDev

In this particular case, we had an outside consultant import some data. The data import needed to be scrubbed but we found ourselves unable to purge the items from the recycle bin, with CS complaining about a colon in the name. In this case, it was the multilingual French name that had a colon. Originally, I had no idea I was looking at a translation issue (i.e. regular : vs ：) so I simply used put all the results into a collection, and then used a LiveReport to query the collection and a WebReport to rename the items (this is CS 10.0 so WR cannot use a collection as a data source directly). The WR pattern match *does* find the colon, and interprets both regular and Unicode colons the same. I'm trying to get the team that did the import to do exactly what they did previously so we can see if we can reproduce. This is all CS 10.0 U 2015-06.

-Hugh

HFCDev

Hi Alex,

We found the use case which caused this. What happened was actually in Web Services. The client app uploaded a document to CS with any colon's already stripped out of the System Default Language. The problem however occurs when the client app sends a WS call to update (add) the French language after initial creation. Because it's an update, the colon check doesn't automatically get invoked, although I would expect that a rename would do the name check, but a RenameMultilingual might not.

Our senior system administrator did this via Web Services. If you try this through the Web UI it does catch it. You may have this fixed in updated versions of CS10.5 and up but you may want to forward this to the WS team.

-Hugh

AKropp

It looks like we may have this fixed. I just used WS to update multilingual metadata and added a French name with the wide-colon to a node. When I go back to it in the GUI the colon remains its proper Unicode representation, and not the reserved normal colon. This is CS10.5 2016-09.

Still can’t locate anything specific to this in the bug tracker, though there are a number of things related to improved handling of multilingual names. One of those may have had the side effect of fixing this too. I’ll check with the PM just to be sure.

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Thursday, October 27, 2016 10:31 AM
To: eLink Recipient
Subject: RE Colons in names - it shouldn't be possible but I've found some

RE Colons in names - it shouldn't be possible but I've found some

Posted by Ferguson, Hugh On 10/27/2016 10:26 AM

Hi Alex,

-Hugh

[To post a comment, use the normal reply function]
Topic:	Colons in names - it shouldn't be possible but I've found some
Forum:	Content Server Development Forum
Content Server:	Knowledge Center CS16

HFCDev

Alex,

I just tried against our CS16 instance. I created a test folder in my Personal WS. I then updated the multilingual Name for the test folder with a name containing a colon (regular colon, not wide). It accepted it without problem. If you then attempt to move that folder, it will fail, complaining about the colon in the name. Here is a snippet of the WS code I ran for this test:

void RunTest(string username, string pwd)
{
string folderName = "TestFolder " + Guid.NewGuid().ToString("N");
string foldernameFR = "FR : " + folderName;
if (Authenticate(username, pwd))
{
Log("Authenticated... Getting personal WS");
Node persWSnode = GetDocMan().GetRootNode(ref otAuth, "PersonalWS");

Log(String.Format("Got personal WS node {0}", persWSnode.Name));

Log(String.Format("Creating folder {0}...", folderName));
Node newFolder = GetDocMan().CreateFolder(ref otAuth, persWSnode.ID, folderName, "", null);
Log("Folder created... Updating metadata");
MultilingualMetadata mdFR = new MultilingualMetadata();
mdFR.LanguageCode = "fr_CA";
mdFR.Name = foldernameFR;

MultilingualMetadata[] md = new MultilingualMetadata[1];
md[0] = mdFR;
GetDocMan().UpdateMultilingualMetadata(ref otAuth, newFolder.ID, md);
Log("Folder updated");
}
else
{
Log("Unable to authenticate!!");
}
}

I used helper functions for geting the Authentication and DocMan clients as well as a Log() wrapper around Console.Log(). I can upload this to my personal WS or an area of your choosing if you want the full code.

-Hugh

AKropp

Hi Hugh,

Looks like you’re doing things more or less the same as I am. I just reran the same code I used before and jammed a regular colon into the name and you’re right – it accepts it without issue. Looks like it’s a bit of a loophole with updating names with this method.

I logged this one as a bug with tracking number LESAPI-2171.

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Thursday, October 27, 2016 12:20 PM
To: eLink Recipient
Subject: RE RE Colons in names - it shouldn't be possible but I've found some

RE RE Colons in names - it shouldn't be possible but I've found some

Posted by Ferguson, Hugh On 10/27/2016 12:17 PM

Alex,

-Hugh

[To post a comment, use the normal reply function]
Topic:	Colons in names - it shouldn't be possible but I've found some
Forum:	Content Server Development Forum
Content Server:	Knowledge Center CS16

HFCDev

Quoted Alex Kropp on 10/28/2016 08:38 AM:

Hi Hugh,

I logged this one as a bug with tracking number LESAPI-2171.

Hi Alex ( and anyone else who might be looking for a fix),

Here is some code I introduced as a patch for our CS 10.0 environment. The same could be done all the way to CS16 as the source for the UpdateMultilingualMetadata is the same between CS 10.0 U2016-06 and CS 16:

// PAT201610270 BEGIN : Do a sanity check on the multilingual data passed in
           if ( ok )
               Assoc chkVal = $LLIAPI.NodeUtil.CheckName( m.fName )
               if !chkval.ok
                   ok = FALSE
                   errMsg = Str.Format("%1 : %2", m.fLanguageCode, chkVal.errMsg )
                   // The above function never sets the apiError feature
               end
           end
           // PAT201610270 END

Insert this just before this comment which is inside the loop that processes each language in the inbound assoc:

// Perform the updates

In the above, I leverage the existing name check in $LLIAPI.NodeUtil.CheckName() that is used by NodeAlloc() for consistency.

You could make a case for putting this check outside the metadata loop and just before the call to $LLIAPI.LLNode.NodeUpdate() but you would either have to loop through your inbound assoc again, or translate the Assoc so that it has the data exactly as $LLIAPI.NodeUtil.CheckNames() is expecting the name assoc (notice the plural there).

Happy patching...

-Hugh