Mattersphere Developers Forum
Would you like to react to this message? Create an account in a few clicks or log in to continue.

Go down
avatar
Heather@FootAnstey
Posts : 57
Join date : 2018-12-19

Search Lists and Precedents? Empty Search Lists and Precedents?

Fri 17 Apr 2020 - 15:25
Original Post: Joe Green 29/10/2014 11:18:58

"Hi all, I'm looking at reducing the amount of scripting we have to do behind our precedents to make them more available to power authors, rather than developers. The first issue I';ve hit is this: I want to be able to show a piece of text on a precedent conditionally. The condition needs to take more than one parameter – in this case a client code and a client group code (it will just return 1 row and column, indicating “yes” or “no” if the client is in the group) I can write this as a simple bit of SQL, but I'm unsure how to make that available in the precedent. My understanding is that you can use a Search List in your precedents, but only if they are basically tied to an OMS object, so you can only pass one parameter, and it has to be whatever the Search List is registered to. So is there any way I can wrap the return value of my SQL statement into a VBA “IF” statement and use it in my precedents? Thanks all, Joe"

Responses:

GaryC 29/10/2014 11:30:58
"Hi Joe,
I would probably look to achieve this via a custom script. You can set up a new script in the sdk which uses CurrentSession.CurrentClient to pull back the info and then following your required conditional logic returns either Yes or No as a string. Within the precedent you can then just call that custom field via SCR_SCRIPTNAME;FIELDNAME.
Hope that makes sense! Gary"

Joe Green 29/10/2014 14:23:00
"Hi gary, thanks for that. Is this the stuff in the Precedent manager documentation, which talks about creating a menu script with methods that return strings, which can then be referenced as doc variables like “SCR_UDPRECEDENT.IsInClientGroup”?
The methods in those examples all have one paremeter of FWBS.OMS.Parsers.IContext. Can I add extra parameters to this (GroupCode in my example, given that the context gives me the client number), so looking like this:
public string IsInClientGroup(FWBS.OMS.Parsers.IContext context, string groupCode)
{
//Get the DataList passing incontext.Client.ClientNo and groupCode
//Read DataListValue into a bool called myBoolean return myBoolean;
}
"

GaryC 29/10/2014 14:33:51
"That's the area, but I'm not sure you'll be able to pass a variable in like that. Where is groupCode stored; Client ext data?"

Joe Green 29/10/2014 14:45:49
"A client can have many groups, so it's not extended data. Normally we surface it with a data list, but that doesn't help directly in the precedent. I can write script in the Merging event to just push out to a custom merge field based on the data list, but as I said, I'm looking for ways to push this kind of stuff back to power author types.
I know there';s no documented way of passing params into those menu script methods, but we haven't used menu scripts in precedents before and I know there have been some quite cute solutions on this forum in the past!
Thanks for looking Gary and I will keep playing the menu script fields for a while to see if there's any mileage in them."

GaryC 29/10/2014 14:49:50
"Could then just pass the client id to the datalist and let the sql query in the datalist do the work?"

Joe Green 29/10/2014 15:09:08
"for these client groups, I currently have one data list that just takes client ID, this can return multiple rows (or none!). Before now, in the merging event, I'd run the data list, and loop round to see if it hit the group code I was looking for. As you say, I could replicate this in the menu script code, which would at least let my power author check whether a client is in a specific group, but it would only work for one group - I'd have to write a new method for every group.
I was hoping to be able to write something that would allow the power author to check for and group code against the client in context, so then the wouldn't have to come to me when they want to check a different group.
One option could be to have a datalist that returns a list of comma separated group codes for the client groups, then the VBA can check for the existence of one that way. This is the best I can come up with so far..."

Joe Green 30/10/2014 10:53:18
"Does anyone know what format you need to put into dbFields to get one of these menu script fields to appear in the precedent field picker?
So I've got a script called UDPRECFIELDS with a public method called MatterRef. I can call this in my precedent by manually adding a merge code called SCR_UDPRECFIELDS;MATTEREF.
In the Prec manager guide, all it says is that I need to add it using SCR as the fldType. I've currently got:
fldType:SCR
fldGroup:FILE (I think this just puts it into the File/Matter group of fields) fldExtended UDPRECFIELDS
fldName: MATTERREF
I tried the whole thing in fldName, but that was no good. Has anyone else managed to get this to work?
Thanks, Joe"

Joe Green 30/10/2014 11:03:28
"Actually, I've got this working now - it did need everything in the fldName, but not quite as I tried the first time: fldType: SCR
fldGroup: FILE (I think this just puts it into the File/Matter group of fields) fldExtended NULL
fldName: SCR_UDPRECFIELDS;MATTERREF




Back to top
Permissions in this forum:
You cannot reply to topics in this forum