Armin does not have any add-ons for sale.

• Is it possible to dynamically remove ability to edit sets of records based on a value in the record itself?

  Support November 21st, 2017 @ 6:08 pm
  

  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!

  View Comment
  
  
• Is it possible to dynamically remove ability to edit sets of records based on a value in the record itself?

  Support November 21st, 2017 @ 5:50 pm
  

  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.

  View Comment
  
  
• Is it possible to dynamically remove ability to edit sets of records based on a value in the record itself?

  Support November 20th, 2017 @ 11:08 pm
  

  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.

  View Comment
  
  
• Is it possible to dynamically remove ability to edit sets of records based on a value in the record itself?

  Support November 20th, 2017 @ 10:22 pm
  

  Hi eggsurplus,

  I am almost there! There's been a slight change in the requirements for this enhancement. There is no longer a need to pull data from the related ParentModule. The field value to inspect is a part of the ChildModule itself.

  Here's how I've got it to work so far:

  <?php
  
  // File Location: custom/modules/ChildModule/views/view.edit.php
  
  require_once(&#039;include/MVC/View/views/view.edit.php&#039;);
  
  class ChildModuleViewEdit extends ViewEdit {
  
      function __construct(){
          parent::__construct();
      }
  
      function display(){
        if ($this->bean->my_field > 1) {
          $queryParams = array(
              &#039;module&#039; => &#039;ChildModule&#039;,
            &#039;return_module&#039; => &#039;ChildModule&#039;,
              &#039;action&#039; => &#039;DetailView&#039;,
            &#039;record&#039; => $this->bean->id
          );
          SugarApplication::redirect(&#039;index.php?&#039; . http_build_query($queryParams));
        }
        else {
          parent::display();
        }
      }
  }
  

  <?php
  
  // File Location: custom/modules/ChildModule/logic_hooks.php
  
      $hook_version = 1;
      $hook_array = Array();
  
      $hook_array[&#039;process_record&#039;] = Array();
      $hook_array[&#039;process_record&#039;][] = Array(
          //Processing index. For sorting the array.
          1,
  
          //Label. A string value to identify the hook.
          &#039;process_record example&#039;,
  
          //The PHP file where your class is located.
          &#039;custom/modules/ChildModule/logic_hooks_class.php&#039;,
  
          //The class the method is in.
          &#039;logic_hooks_class&#039;,
  
          //The method to call.
          &#039;process_record_method&#039;
      );
  
      $hook_array[&#039;before_delete&#039;] = Array();
      $hook_array[&#039;before_delete&#039;][] = Array(
          //Processing index. For sorting the array.
          1,
  
          //Label. A string value to identify the hook.
          &#039;before_delete example&#039;,
  
          //The PHP file where your class is located.
          &#039;custom/modules/ChildModule/logic_hooks_class.php&#039;,
  
          //The class the method is in.
          &#039;logic_hooks_class&#039;,
  
          //The method to call.
          &#039;before_delete_method&#039;
      );
  

  <?php
  
      if (!defined(&#039;sugarEntry&#039;) || !sugarEntry) die(&#039;Not A Valid Entry Point&#039;);
  
      class logic_hooks_class
      {
        function process_record_method($bean, $event, $arguments)
        {
          if ($bean->my_field > 1) {
            // inject javascript code here to remove edit/delete/checkbox buttons on page
            print &#039;
            <script type="text/javascript">
            $(document).ready(function() {
              $(":checkbox[value=&#039;. $bean->id .&#039;]").remove();
              $(".edit-link[id=edit-&#039;. $bean->id .&#039;]").remove();
              $("ul#&#039;. $bean->id .&#039;]").remove();
            });
            </script>
            &#039;;
          }
        }
  
        function before_delete_method($bean, $event, $arguments)
        {
          if ($bean->my_field > 1) {
            $queryParams = array(
              &#039;module&#039; => &#039;ChildModule&#039;,
              &#039;action&#039; => &#039;DetailView&#039;,
              &#039;record&#039; => $bean->id,
            );
            SugarApplication::redirect(&#039;index.php?&#039; . http_build_query($queryParams));
          }
        }
  
      }
  

  The first block of code is guided by your direction. It is a custom view.edit.php file that detects a specific field value for the record it is about to display, and if the value condition is met, redirect the user to that records detail view.

  The next two blocks go together, they are logic hooks. The process_record_method injects jQuery to remove edit/delete elements from the UI. And the before_delete_method redirects a user to the record's detail view if they try to delete the record. This, however, has some unexpected results if the record is a part of a bulk-change using checkboxes. But that has been circumvented because the checkboxes are removed from the list-view.

  I have one more issue to figure out and that is how to inject javascript for the subpanel when ChildModule's list-view is populated there. Can you help me out in this regard?

  View Comment
  
  
• Is it possible to dynamically remove ability to edit sets of records based on a value in the record itself?

  Support November 20th, 2017 @ 4:50 pm
  

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

  View Comment
  
  
• Is it possible to dynamically remove ability to edit sets of records based on a value in the record itself?

  Support November 20th, 2017 @ 3:45 pm
  

  I think the best way to do this is in addition to your suggestions by removing the ability to edit by modifying view.edit.list (among other files), is to have a subpanel list view .tpl file, and put templating logic in there that removes the edit button row-by-row if a field in that row has a specific value. Although, I'm not sure how to do that.

  View Comment
  
  
• Is it possible to dynamically remove ability to edit sets of records based on a value in the record itself?

  Support November 20th, 2017 @ 3:15 pm
  

  I think the issue I'm running into is that the EDIT button is not a field in the module's database, it's part of the UI alone. I can find some logic that modifies each record as it is pulled from the database, but I cannot see where the code for the EDIT button is stored, and furthermore I'm not sure how to differentiate the List View for the module itself, or the List View for the Module when it's in a Subpanel. There seems to be some code that changes both, and some code that changes only one. I'm still not entirely sure what to do for this issue.

  View Comment
  
  
• Is it possible to dynamically remove ability to edit sets of records based on a value in the record itself?

  Support November 19th, 2017 @ 8:10 am
  

  Hi eggsurplus,

  Can you provide some additional direction on your suggestion?

  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.

  I'm currently trying to find the code responsible for populating the list view. There must be some sort of loop somewhere. I also found that it may be possible to hook into this using logic hooks process_record event.

  Can you provide some guidance?

  View Comment
  
  
• Is it possible to dynamically remove ability to edit sets of records based on a value in the record itself?

  Support November 16th, 2017 @ 4:43 pm
  

  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!

  View Comment
  
  
• Is it possible to dynamically remove ability to edit sets of records based on a value in the record itself?

  Support November 16th, 2017 @ 4:20 pm
  

  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.

  View Comment
  
  

Armin has not rated any add-ons.

Armin has not verified any add-ons.

Armin has not created any Wanted Add-ons.