SecuritySuite - Enhanced SuiteCRM Teams

Jason, Thanks so much for the quick reply! I'm not so sure I explained the situation accurately. You are probably still right in assessing that SecuritySuite might not be involved. I'll give a better description.

Parent Module - has a field called "total", and values for "total" can only be either 1, 2, 3, or 4. Child Module - has a many-to-one relationship with the parent module, meaning if I look at the detail view of the Parent Module, I will see a subpanel with many records of the Child Module.

When looking at the detail view of a Parent Module record, and if that Parent Module record's "total" value is 1, then all the Child Module records in the subpanel should not have an EDIT button at the end of each row.

That's exactly how I understood it. How I tackle this requirement is to first ensure that an actual edit and save cannot happen if the parent module total = 1. That requires editing the child module bean's save() to check for that parent module total value to prevent a save. Then to prevent an edit alter the view.edit.php view in the child module to check for that total value then redirect to the detail view if total = 1.

With those mechanisms in place the next step is to remove the edit button. This I don't have a solution for off of the top of my head, but where there is a will there is a way with SuiteCRM. Could simply be a js solution which would be acceptable if you have the safety mechanisms above done.

Thank you so much for your valuable insight, Jason. I will tackle this issue using your approach which makes total sense to me. I will follow up with you as soon as I figure things out more completely. Thank you!

You're welcome! I'm looking forward to hearing what you came up with. I'll close this case out, but feel free to follow up here.

For the list view use the get_list_view_data() function in your bean class. Only the data shown in your list view will be included here. However, you can add query only fields that don't display on your list view, but will return in the data passed to that function by adding the field in your listviewdefs.php similar to:

  'MY_CUSTOM_FIELD' => 
  array (
    'width' => '0',
    'default' => true,
    'sortable' => false,
    'label' => '',
    'customCode' => ' ',
  ),

Or if this is for your subpanel add the field to your subpanel def similar to:

        'my_custom_field'=>array(
            'name'=>'my_custom_field',
            'usage' => 'query_only',
        ),

Or just the ID passed to the function and retrieve the bean, but that will often require another db query behind the scenes.

What you can do in get_list_view_data():

    function get_list_view_data(){
        global $db, $system_config, $current_user;
        $temp_array = $this->get_list_view_array();

        if($temp_array['TOTAL'] == '1') {
            $temp_array['SOME_OTHER_FIELD'] = '{removed}';
        }
        return $temp_array;
    }

Hope this helps.

I honestly have no idea which files to place this code in.

The get_list_view_data() function is part of SugarBean. Your custom module will have a class that extends this. The function would go in that class.

The query_only thing above it goes into your /modules/YOURMODULE/metadata/subpanels/default.php or whichever subpanel layout you wish. This is only to get that data into your get_list_view_data() function.

This is why it's important to make sure that editing isn't possible even if they click on the Edit button. Once that is in place then you can look at using javascript to remove the Edit buttons or start working backwards through the code to find where in /include/ListView or /include/SubPanel the Edit button gets added and how to override that functionality.

Good job making it this far! It's painful now, but it'll feel easier to do down the road.

For injecting javascript I suggest just echoing it out in your view.detail.php for the parent module and do an on ready. I'm not able to help with the actual js for your specific needs, but this will get it out on the page at least.

Alternatively, use an after_ui_frame global hook, check for the current module, and if it is the parent module and detail view then output the js, but that may have problems in ajaxui mode.

That's a really good idea to use the ParentModule's detail-view file to inject the javascript that handles the subpanel UI. I hadn't considered that option.

Ideally I'd like to keep all the code/logic within the ChildModule directory. There's got to be a way to handle the javascript injection directly into the subpanel view as it loops through the records.

Hi eggsurplus,

I greatly appreciate all of your time and guidance in this effort! It has helped me immensely to figure out how to implement these changes in an upgrade-safe manner.

You were correct and I am able to inject jQuery code to the ParentModule detail view which handles modifying the UI of its subpanel for the ChildModule. The only issue I have now is intelligently detecting when the EDIT button appears as a user navigates through list pages within the subpanel using left/right arrows within the subpanel.

For future reference, it looks like the subpanel list is populated with javascript, and it is populated using this file: include/SubPanel/SubPanelTiles.js. I will need to add some jQuery to detect when new EDIT buttons appear, and then remove them immediately from the UI. I will report back here when that is done with the code. Here is the code I have so far:

<?php

// File Location: custom/modules/ParentModule/views/view.detail.php

if(!defined(&#039;sugarEntry&#039;) || !sugarEntry) die(&#039;Not A Valid Entry Point&#039;);

require_once(&#039;include/MVC/View/views/view.detail.php&#039;);

class ParentModuleViewDetail extends ViewDetail {

    function __construct(){
        parent::__construct();
    }

  function _displaySubPanels(){
    global $db;
    require_once (&#039;include/SubPanel/SubPanelTiles.php&#039;);
    $subpanel = new SubPanelTiles($this->bean, $this->module);

    // disable inline edit if criteria is met
    if ($this->bean->my_field > 1) {
      print &#039;
      <script type="text/javascript">
      $(document).ready(function() {
        $("table.subpanel-table tbody tr td ul.clickMenu").remove();
      });
      </script>
      &#039;;
    }

    echo $subpanel->display();
  }

}

This code works for the initial list that is populated in the subpanel, but when a user clicks the right/left arrow buttons within the subpanel, the EDIT buttons re-appear for the new populated list. I will post my code as soon as I get it working to remove all EDIT buttons from each row within the subpanel.

Thanks again for all your help eggsurplus. Your insight has proven invaluable.

I got it to work by locating a jQuery plugin that detects when a specific DOM element changes the contents within it, whatever it may be. It's called initialize.js located here: https://github.com/pie6k/jquery.initialize I included the initialize.js file before my own jQuery.

I wrapped the logic to remove the EDIT button within the initialize function and it works great!! Here's the code below:

<?php
if(!defined(&#039;sugarEntry&#039;) || !sugarEntry) die(&#039;Not A Valid Entry Point&#039;);

// File Location: custom/modules/ParentModule/views/view.detail.php

require_once(&#039;include/MVC/View/views/view.detail.php&#039;);

class ParentModuleViewDetail extends ViewDetail {

    function __construct(){
        parent::__construct();
    }

  function _displaySubPanels(){
    global $db;
    require_once (&#039;include/SubPanel/SubPanelTiles.php&#039;);
    $subpanel = new SubPanelTiles($this->bean, $this->module);

    // disable inline edit if criteria is met
    if ($this->bean->my_field > 1) {
      // clickMenu  SugarActionMenu
      print &#039;
      <script src="custom/modules/ParentModule/js/initialize.js"></script>
      <script type="text/javascript">
      $(document).ready(function() {
        $.initialize("table.subpanel-table tbody", function() {
          $("table.subpanel-table tbody tr td ul.clickMenu").remove();
        });
      });
      </script>
      &#039;;
    }

    echo $subpanel->display();
  }

}

The only caveat so far is that this jQuery also removes the CREATE button within the subpanel, which is not what I want to do. But the only thing I need to do to fix that is change the jQuery selector table.subpanel-table tbody tr td ul.clickMenu to either more intelligently target the EDIT buttons only, or to remove the CREATE button from the selector. Other than that small change, the code works perfect!

I will consider adding more jQuery on other pages to handle the "Recently viewed" EDIT buttons that sometimes appear in the primary navigation dropdown menus.

Thanks again eggsurplus!

Fantastic work!