Mandatory Field for specific Group (not state transistion)

[DanR.]

Is there a way to make a field mandatory for a specific group? We are using MKS Integrity 2009 SP5. I now we need to update it with the latest SP.

I have a work flow that after intial input the state is set to 'Ownership ID'. An email notification is sent to 5 different groups. Each of the groups has custom fields for their group. Each group has a custom integer and Longtext field that they must provide input to (I.E. the mandatory fields). The state does not change until all 5 groups have provided thier input. How can I do this?

[jgorsline]

Daniel,

There are two answers for your question.

First, starting in Integrity 10.1, we introduced a new constraints system that would make this much easier to do as it give a lot more flexability over options such as this.

In earlier versions, however, the best way to do this would be to use a pre-trigger to check the field and the user group and either stop the submit or let it pass based on the rules you put in the script.

[DanR.]

pre-trigger? Which trigger? We're not using version 10, we use 2009. I'm not a script expert, so we have been using the out-of-the-box scripts with minor modification.

[jgorsline]

Unfortunately, there is not an out of the box trigger for this. It is not a complicated trigger, but it would have to be written specifically for this situation either by your team or our services team.

[matt_giltaji]

I have used pre-triggers to enforce that only a specific group is allowed to make certain changes (basically a makeshift fine grained editabilty rules), I have also used pre-triggers to enforce that certain fields are mandatory if other fields have specific values (this is what Jeremy mentioned is replaced by Constraints in 10.1).

If the goal is for when Group A edits the Issue, they are informed that fields X, Y, and Z are for them, I am not sure if there is an elegant way to do that.

As a workaround, you could make a rule-based pre trigger which runs whenever the custom fields are updated to check the group membership of the user and error out unless all of their group's mandatory fields are filled out, but that may or may not be helpful.

Another idea might be to use sub-items underneath the item in "Ownership ID" state. These items could be permissioned to each of the specific groups and have the custom fields for that group set as mandatory for the type. That way in order for any user to close the sub-item to move the parent forward, they would need to fill out their custom fields.

The sub-item concept has been useful for us but it does add a lot of complexity and would probably require some custom trigger script writing.

Matt

[jgorsline]

Thanks Matt, that's where I was heading.

You could set a pre-trigger that grabbed the user group and ensured that the mandatory field for that group is entered how you require.

A second small post trigger could be put in place that checked the document to see if all the fields were set and change the state as you required.

[DanR.]

Thanks for you help Matt, but I'm afraid we are going to have to change tools. MKS is not working for us. The suggestion you provided is not viable at all.

[DanR.]

I just need a script that checks if the user is in a certain group and to make a field mandatory. The only thing special for this script would be the field name and group.

[mrump]

Hi Daniel,

reading all the answeres above I think they missunderstood your intentions. As as far as I get it:

- you have an item in "initial" state and you you want to start a workflow that collects input from 5 different groups of users by transfering it into "Ownership ID" state. correct?

While the item is "waiting" for it's state transition:

- each group has it's own set of mandatory fields and

- only if all fields from all groups are filled, the the state transition from "initial" to "Ownnership ID" is completed. Correct?

Please answer if I am rigth, because help is possible 😉

even in 2009

[DanR.]

You are kind of right. Each group has fields we would 'like' to be mandatory, but because it only works with state transition we cannot do it. I understand that a script would work, but I do not know where to start. The MKS... err PTC documentation is to generic and does not explain things well. Is this the price we must pay for a tool that is highly customizable? Yet that could be it's downfall.

[mrump]

Hi Daniel,

there are some facts:

- in Integrity prior version 10.1 you cannot change the "mandatoryness" of fields dynamically. A field can only be mandatory for a state change.

- the Trigger api is quite generic and you can get almost all the information you need, but only if you know where to look.

Nevertheless, as far as I understand your use case, here's what I would do:

Assuming the info you request from the 5 groups is some kind

sequential you could create 5 states ("requesting info from group x") and allow the transition only for the appropriate group. You set the mandatoryness of the according fields for each state separately.

Assuming there is no "order" in the groups and you want to be more flexible, I would create only one extra state "collect data" and the transition from "collect data" to "ownership ID" would only be allowed for the admin group.

Then I would set up the fields (e.g. 3 fields per group) in a way thy each group member in question could only edit it's own group's fields.

Then I would write a trigger (maybe scheduled daily) "autoPromoteItemState" that uses a query "all item in state 'collect data'". This trigger checks whether all fields are filled out and if so it changes the Items state to "ownership ID".

All you need for a trigger like this, you can find in the sample part of you installation

For the scheduled trigger you need something like this:

..

// Main execution block...
function main()
{

// get the items defined by the trigger's query
var issues = args.getIssues();

for (var i = 0; i < issues.length; i++) {
// get a "writeable" bean for each item
var itemDeltaBean = serverBean.getIssueDeltaBean(issues[i]);

//check the items content

if(allMandatoyFieldsFilled == true){

itemDeltaBean.setState("my new state");
}
}
}

}

var environmentBean = bsf.lookupBean('siEnvironmentBean');

var serverBean = bsf.lookupBean("imServerBean");

var params = bsf.lookupBean("parametersBean");

var args = bsf.lookupBean("imScheduleTriggerArgumentsBean");

HTH

Matthias

[DanR.]

Yes, I initially created a state for each of the 5 groups, however, there is no order and that slows the process. That being said, the alternate solution could work kind of. The only problem is the user in one of those groups is not prompt to enter data into the manadatory field.

Is it possible that a trigger script could be written to display an error message. For example, one of the users in the group is editing an issue and fails to enter data into one of the mandatory fields, and when they try to save the issue an error message pops up saying "Error - Field X is mandatory..."

Thoughts?

Thanks,

Dan

[mrump]

Hi Daniel,

unfortunately there is no such thing as a "interactive Dialog" possible in a serverside trigger script.

The only thing you can do is "abort" the transaction in a pre-event trigger (see the "abortSubmit.js" trigger in the samples). This allows you to check any precondition you like in your trigger code and even submitting a custom error message. In case this trigger fires, , the use will stay in his opened edit view and the submission of the item was simply rejected.

HTH Matthias

[DanR.]

Remains unresolved.

[jgorsline]

Daniel,

I think this issue needs more attention than the community set up can provide. I would like to ask you to open a support case so that an engineer can properly research and walk through this with you.

You can open a case with our support team here:

https://www.ptc.com/appserver/cs/case/case_logger.jsp