Can't hide fields on view screen using behaviours

[Richard Burstiner]

I have behaviors set up to hide fields based on a user's custom field group membership (Group Responsible). The behavior works perfect on create and edit screens but is ignored on the view screen. Any ideas where I went wrong? Thank you.

My behavior setup is:

Here is the XML:

<config name="ITS: Hide Notes" use-validator-plugin="false" guideWorkflow="null">
<field id="customfield_11010" validator-script="" validator-class="" validator-method="" readonly="false" required="false" hidden="true" validator="server">
<except custom-field-group="customfield_11005"/>
</field>
</config>

[Jenna Davis · Accepted solution]

Hello, 

Behaviours don't work on the view screen. They only function on the Create/Edit screens and the other screens mentioned here. On the view screen, any field with a behaviour on it will simply open an Edit window when clicked, as explained in the documentation. 

This post talks about a few other options you could look into, sorry I can't help you out here more!

Please let me know if you have any further questions. 

Jenna

[Richard Burstiner]

Any idea if the behaviors ever will work on view screens?

[Daniel Garcia]

Behaviors must be working on the view page.

• If I pepper log.error statements throughout my init script I can verify that it runs
• Fields that have has setReadOnly applied no longer are editable via the inline edit while those that haven't continue to be edittitable

I think what you mean is that behaviors work differently on the view page

[Daniel Garcia]

I've got a workaround for this.

I have a javascript file that is loaded from the announcement banner. I've extracted the relevant bits here

var gOpMode = null;                // TABLE, VIEW, CREATE, EDIT, WORKFLOW
var gDeferedValidationData = null; //Because sometimes event_scriptrunner_validation is called before tailor_issueView

//This function gets called when a new issue is displayed on the page in view mode
function tailor_issueView() {
    gOpMode = 'VIEW';
    if (gDeferedValidationData!=null) {
        event_scriptrunner_validation(gDeferedValidationData);
    }
    //...
}

//This function is called when new behaviour data arrives
function event_scriptrunner_validation(data) {
    if (gOpMode==null) { //potential concurrency issue here
        gDeferedValidationData = data;
    } else {
        gDeferedValidationData = null;
        $.each(data,function( fieldname, fieldData ) {
            if (fieldData.hidden && gOpMode=='VIEW') {
                if (fieldname.substring(0,12)=='customfield_') {
                    $('div#customfield-tabs ul.property-list li#rowFor'+fieldname).hide();
                } else {
                    $('ul#issuedetails li.item span#'+fieldname+'-val').parent().parent().hide();
                }
            }
        })
    }
}

(function ($) {
    $( document ).ajaxComplete(function(event, xhr, settings) {
        if (settings.url.includes("/rest/scriptrunner/behaviours/latest/validators.json")) {
            let responseData = null;
            try {
                responseData = JSON.parse(xhr.responseText);
            }
            catch(err) {
                console.error(err.message);
            }
            if (responseData) {
                event_scriptrunner_validation(responseData);
            }
        }

        //Psuedo Code for Simplification here. My actual script is quite a bit more complex
        if (some condition) {
            tailor_issueView();
        }
        //Psuedo Code for Simplification here. My actual script is quite a bit more complex
        if (begining of page load process) {
            gDeferedValidationData = null;
        }
    });
})(AJS.$);

[Richard Burstiner]

Daniel, thank you so much for taking the time to post your reply. Adaptavist had replied that behaviors do not work on the View screen. 

Due to time and effort, we had to go a different route and (believe it or not) purchase a plugin called "Secure Fields for Jira" which makes it quick and easy to apply this kind of security.

I hope someone can benefit from your answer.

[Sam007]

@Jenna Davis It's not opening edit window on the view screen, I have also set behaviour for that field. More details are over here - 

https://community.atlassian.com/t5/Jira-questions/ScriptRunner-Behaviour-not-opening-edit-screen-when-clicked-on/qaq-p/924081#M296324

[Sir Charles Amante]

Hi @Daniel Garcia 

I'm trying to get your script to function as it looks like the most robust solution. I've loaded it using JsIncluder, but I'm not entirely sure what to replace your pseudo code with to have it actually run when a new issue is displayed or when behavior data arrives.  

[Daniel Garcia]

This is closer to what I actually run, but I still chopped huge sections out for simplification and haven't tested the result. My actual script is 4000 lines.

Depending on your version of JIRA, events fire off at different times and you need to clear, set or tailor things based on different events. When we upgraded to 7.13.0 things had changed quite a bit and it took me a while to figure out when best to do stuff.

var gOpMode = null;                // TABLE, VIEW, CREATE, EDIT, WORKFLOW
var gDeferedValidationData = null; //Because sometimes event_scriptrunner_validation is called before tailor_issueView

//This function gets called when a new issue is displayed on the page in view mode
function tailor_issueView() {
    gOpMode = 'VIEW';
    if (gDeferedValidationData!=null) {
        event_scriptrunner_validation(gDeferedValidationData);
    }
    //...
}

//This function is called when new behaviour data arrives
function event_scriptrunner_validation(data) {
    if (gOpMode==null) { //potential concurrency issue here
        gDeferedValidationData = data;
    } else {
        gDeferedValidationData = null;
        $.each(data,function( fieldname, fieldData ) {
            if (fieldData.hidden && gOpMode=='VIEW') {
                if (fieldname.substring(0,12)=='customfield_') {
                    $('div#customfield-tabs ul.property-list li#rowFor'+fieldname).hide();
                } else {
                    $('ul#issuedetails li.item span#'+fieldname+'-val').parent().parent().hide();
                }
            }
        })
    }
}

(function ($) {

    $( document ).ajaxComplete(function(event, xhr, settings) {
        if (settings.url.includes("/rest/scriptrunner/behaviours/latest/validators.json")) {
            let responseData = null;
            try {
                responseData = JSON.parse(xhr.responseText);
            }
            catch(err) {
                console.error(err.message);
            }
            if (responseData) {
                event_scriptrunner_validation(responseData);
            }
        }
    });

    JIRA.bind(JIRA.Events.NEW_CONTENT_ADDED, function(e, context, reason) {
        if ($("#issue-content").length()>0) {
            if ((reason=='dialogReady' && contextref=='DIV.jira-dialog-content') || (reason=='panelRefreshed' && contextref=='DIV#details-module.module.toggle-wrap')) {
                $("div#issue-content").removeAttr("tailored");
                g_opmode = null;
                gDeferedValidationData = null;
            }
            if((reason=='panelRefreshed' && (contextref=='DIV.issue-view' || contextref=='DIV.issue-search' || contextref=='DIV#details-module.module.toggle-wrap')) ||
               (reason=='pageLoad' && contextref=='DIV.issue-container'))
            {
                var customfieldmoduleLength = 0
                var customfieldmodule = $("div#customfieldmodule").html();
                if (customfieldmodule!=null) {
                    customfieldmoduleLength = customfieldmodule.length;
                }
                if (customfieldmoduleLength>0) {
                    var issueContent = $("div#issue-content");
                    var currentTailored = $(issueContent).attr("tailored");
                    if (currentTailored==null) {
                        $(issueContent).attr("tailored",issueKey);
                        tailor_issueContent();
                    }
                }
            }
        }
    }
})(AJS.$);

[Aaron Smith]

 https://scriptrunner.adaptavist.com/latest/jira/behaviours-overview.html#_limitations

In the documentation it has the line below. It seems like that is an incorrect statement. 

On the View Issue screen, trying to edit a field with a behaviour will launch the edit issue screen, instead of the normal inline editor.

[Jenna Davis]

Sorry for my late reply on this thread!

I believe this feature (opening a popup edit issue screen instead of opening the inline editor) may be being effect by a bug in our backlog. See: https://productsupport.adaptavist.com/browse/SRJIRA-3004

A fix for this issue is awaiting release, but if you're still having problems getting this to work after the fix comes out I'd recommend you head to the ScriptRunner support portal and put in a ticket - the support agents and devs will be able to help you out over there. :) 

Jenna

[JacksonC]

If you run the below, it should still allow you to inline edit.

getFieldByName("XXXX").setAllowInlineEdit(true)

[Rajesh Kamisetti]

Hello, 

We can hide any field in the view screen with the script Fragments by following the steps.

Regards,

Rajesh.K

[Sir Charles Amante]

Thanks for this! How would you do this using a custom field name instead? We're just finishing converting every field ID to a field name so that our customizations are portable. 

[Rajesh Kamisetti]

Hello Charles,

Sorry, we can't do this by custom field name as we are hiding the field using Html code.

See the below image for the ref

 

[Witold Z_]

Hi Rajesh,

Is it possible to change the customfield_10600 label or title considering the example above? Can you explain that?

[Brent Nye]

I'm curious as to how the Key was determined. It seems inconsistent, with an extra space between Color and field no hyphen/dash between View and screens. Thank you.

[SKAdmin]

Incase anyone needs help with an inverted condition. 

import com.atlassian.jira.component.ComponentAccessor

def currentUser = ComponentAccessor.jiraAuthenticationContext.loggedInUser

def groupManager = ComponentAccessor.getGroupManager()

!((groupManager.isUserInGroup(currentUser, 'GroupA')))

writer.write ("""

<style>

#rowForcustomfield_18600{

    display: none !important

    }

    </style>

    """)

[Damon Curnell]

I used a scripted field to copy display the contents of the field based on group membership.  The solution employs two fields.  In this case Knowledge Base and Knowledge Base. 

I place the editable field on the edit/create screen and the scripted field on the view.

{code}

// Scripted Field Knowledge Base.  

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.user.ApplicationUser

def customFieldManager = ComponentAccessor.getCustomFieldManager()
def user = ComponentAccessor.jiraAuthenticationContext.getLoggedInUser()
def groupManager = ComponentAccessor.getGroupManager()

def Collection<String> members = groupManager.getUserNamesInGroup("Restricted Group")

def String returnString = ""
for (String member: members){
   if (member.equals(user.getName())) {
     def fld = customFieldManager.getCustomFieldObjectsByName('Knowledge Base')
     returnString = fld[0].getValue(issue)
  }
}
return returnString

{code}

Of course inline edit does not work