I think you may have to use a SQL trigger to concatenate the CreateIdentity of the Id attribute to your required prefix.
This is something I'll be trying on our DEV system at the weekend.
We have built two processes within the Call Management Module, Release and Triage. I used this trigger to grant a separate prefix; seems to work ok.
/****** Object: Trigger [dbo].[I_POPULATE_CALL_REF] Script Date: 10/22/2015 10:56:40 ******/
SET ANSI_NULLS ON
SET QUOTED_IDENTIFIER ON
ALTER TRIGGER [dbo].[I_POPULATE_CALL_REF] ON [dbo].[ca_call]
declare @call_id int,
declare @prefix_char varchar(6),
select @call_id = ca_id,
@call_guid = pm_guid
if (select usr_releasetypecall1 from inserted) IS null
set @prefix_char = 'TRI/'
if (select usr_releasetypecall1 from inserted) IS NOT null
set @prefix_char = 'REL/'
set @call_reference = @prefix_char + convert(varchar,@call_id)
set usr_processref = @call_reference
where pm_guid = @call_guid
Ok, that's great, I've found the triggers and created one against the table for the main business object in my new module and it creates the process ref for the main business object in the process management module, but there appears to be a missing attribute on the task business object that was created namely some sort of serial number (this appears in all collections by the looks of it) that sequential increments for each task added against each record in the main business object. I'm not sure what function within LANDesk or SQL is populating this serial number and the attribute wasn't created automatically in the tasks business object when creating the new module as it was in all the other collections that were created. Could be a bug I guess?
Thanks for that, it works and creates a serial number field that I can use in the process ref, but I think there might be something else wrong as the 'default' serial number which if i'm not mistaken is coming from the 'Process Management\Process\id' is filled with 0's, this is what is appearing in the history of events against each ticket, not sure if I can change what is displayed in the history query, but I'd say that some sort of serial number attribute should have been created when the object was created by the create new module wizard.
I got our SQL trigger working on the Top Level BO, but I think I've hit something similar on the Tasks object within the newly created module. (I've logged it with support)
Did you get anywhere with this at all?
Yes, I managed to get it all working. I had to add my own serial number attribute to the 'Tasks' business object that was created and wrote a 'before save' BOO calculation to populate it, this is then used in the trigger to populate the process ref. The issue I now have is that unlike all the other Task BO's in other modules (out of the box modules), these appear to have a serial number field already that does not require some BOO to populate it, this attribute is also the default serial number in the history pane. So in my new module all the Tasks that are added have a serial number of Zero as you cannot make it the 'Is Name?' attribute for the BO.
static def GetAttributeValue(NewModuleTask):
Value = NewModuleTask._NewModule._Tasks.Count
"So in my new module all the Tasks that are added have a serial number of Zero as you cannot make it the 'Is Name?' attribute for the BO."
I raised that with support. They came up with a SQL script to run to switch the IsName on for the serial number attribute. It's GUID specific though. I'm hoping to discuss running that with our DBA today sometime.
That sounds interesting, let me know how you get on with it, I'd like to give that a try.
The script did the job and I'm now getting the correct headers on the Tasks and in the WebDesk History pane.
As it's GUID dependent you're probably best off contacting support and getting them to advise rather than me posting it here.