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.
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. 🙂
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
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.