Commodore
Commodore
1382 views

The opposite of "assignment isin $lo.assignments"

Jump to solution

What is the contrary of "assignment isin $lo.assignments"?

I need to do a "assignment isNOTin $lo.assignments".

I tried to search through the documentation and foruns and couldnt find.

0 Likes
17 Replies
Commodore
Commodore

You can accomplish your request by creating a Rulset with rules to run on the phase level of a workflow. You will need to add the Ruleset to the phase level On Display. You will need to create variables within the rules to identify who can have write capabilities. You will need to use your variables to add on the form. For example, on a form displayed during Assignment phase, you can have a read-only condition for the Title field, which is [$ReadOnly] = true. Your Ruleset On Display rules will determine if the person looking at ticket has their $ReadOnly variable set to true or false. For example, there can be a rule to setting variable $ReadOnly to false if the person looking at the ticket is a member of the assignment group on ticket. You will need to build out all your variables and rule conditions. Keep in mind, Service Manager has multiple ways of accomplishing the same task. 🙂

Joe

0 Likes
Commodore
Commodore
Thing is, the version is 9.32, there is no Ruleset in this version.
0 Likes
Vice Admiral Vice Admiral
Vice Admiral

Hi,

Just giving some random solution for your requirement, the expression you are looking for may not yield the result you are looking for.

create a array field if you are looking for multiple group access(if engaged in the ticket) or you may create logical field
create a Rule for not same(assignment in $L.file, assignment in $L.file.save) or assignment in $L.file~=assignment in $L.file.save
store assignment in $L.file value

now you can write condition on new field, along with.. like below(not tested the below expression)

assignment isin $lo.pm.assignments or NewField isin $lo.pm.assignments

 

0 Likes
Commodore
Commodore

Hi @Sbox 

Overwriting an attribute with the previous record value to hinder the user modifying an attribute does not sound like the right strategy (not providing the best usability).

Possible strategies are:

- Use the Displayscreen I/O condition in order to decide if the complete record is read-only or not. Provide a displayoption e.g. executing a script (script.execute) or wizard (wizard.run) that allows the user to nevertheless provide a new comment and save the record - in case of Process Designer this can also be done via Phase Form Edit Conditions / Actions.

- Use datapolicy "read-only" conditions to decide if a certrain attribute shall be read-only or not (supports as well jscall in case conditions are complex) - this is quite powerful and provides a good performance since these Statements are evaluated server-side (much better than DVD read-only conditions). This would easily allow to make all desired attributes read-only but still provide the new comment (e.g. $pmc.actions, $apm.activity on the Incident) editable.

View solution in original post

Commodore
Commodore
Thanks for the replies. I have been absent, I will try Alan's solutions, and Ill update the topic.
Commodore
Commodore
Thanks for the suggestions, I was able to create a DO, through a wizard was able to do what I wanted.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.