Showing posts with label hack. Show all posts
Showing posts with label hack. Show all posts

Monday, February 27, 2012

Select All Visible or Read-Only Checkboxes in Field-Level Security

It looks like I'm not the only one who has historically wanted a way to mark all Visible or Read-Only checkboxes on the Field-Level Security page in Salesforce.

Fortunately, while Salesforce (hopefully) works to make this a standard feature, administrators can use the following bookmarklets on this Salesforce Hacks page:
  • Mark all fields as visible
  • Mark all fields as read-only

Try it out with a profile in your org!

Sunday, December 18, 2011

ApplyYourself Hack to Mass Update Choice Group Values

How annoying is it that there is no easy way to mass update choice group values in ApplyYourself? All mass updates have to be sent to an account manager, who then uses some magical tool to make the changes that should've taken 1 minute for an administrator to complete.

For a change that I needed to make immediately, outside of business hours, I had to come up with an alternative: ChoiceGroupUpdateHack.js

When this script (making sure the code is prefixed with javascript:) is entered into the address bar and executed, a small textarea element is created at the top of the page along with an Update Values button.


To use the hack UI, all one has to do is paste new values directly from Excel into the textarea element and then click the button!


The Excel spreadsheet should be formatted as it is exported from ApplyYourself. The spreadsheet should include the following columns, in order:
  • Choice Value
  • Choice Code
  • Choice Order
  • Header: "Yes" or blank
  • Related Value
  • Inactive Date: MM/DD/YYYY

Although this hack took 3 hours to develop, the ability to mass update choice groups on demand autonomously is priceless to me.

Note: If ApplyYourself starts throwing bizarre errors that don't make sense, another hack may be necessary to clear the choice group before loading the new values: ChoiceGroupClearHack.js

This hack was validated in Safari 5.1.2 and in Google Chrome 16.0 on Mac OS X Lion.

Friday, December 16, 2011

ApplyYourself Hack to Use Free-form Text Filters for Choice Group Fields

I discovered an interesting bug in ApplyYourself that makes it possible to do something that should've been standard functionality: Setup normal text filters using the Contains operator with Choice Group fields.

Imagine trying to get a list of all records that have Program value containing the word "Bachelor" when your Program field is setup as a Choice Group with over 100 options. The standard query interface forces you to use the following filter:
  • Program In this List ... (manually selecting every singe value using the tiny 3-line picklist)

Or, you may have smartly added "Bachelor" as an extra value to the associated Choice Group so that you can select that single value when using the Contains operator.

However, both of these methods are annoyances. What if I wanted to query something on the fly with a value that I haven't predicted to need before?

The hack workaround or solution is simpler than both alternatives:
  1. Setup the filter with the desired field and the Contains operator with any value at all.
  2. Click save and run.
  3. Click the Back button in your browser, not in ApplyYourself. The picklist will have now magically turned into a free-form text field!

Friday, December 2, 2011

Streamlined Login for MediaWiki

I love MediaWiki overall, but I cannot stand the way the login prompt works when an unauthenticated user tries to access a protected page.

The tedious process is basically as follows:
  1. User clicks a link to a protected page. A page with "duh" instructions is displayed, forcing the user to click a link to get to a login form.
  2. User clicks the link to get to the login form. Why doesn't the login form automatically give focus to the Username field?
  3. User clicks in the Username field just to start typing in a username.

The process really should be as follows:
  1. User clicks a link to a protected page.
  2. User immediately starts typing a username.

So, to make it easier for users to like and adopt our MediaWiki instance, I customized two files: /includes/OutputPage.php and /includes/templates/Userlogin.php.

In case anyone wants to easily copy the code, I've uploaded my notes on this hack. Now I'm finally ready to start publicizing our MediaWiki internally and getting people excited about it!

This hack was tested on the following browsers in Mac OS X Lion:
  • Safari 5.1.1
  • Firefox 8.0.1
  • Chrome 15.0

Note: This implementation causes the instructions page to fully load before JavaScript redirects the user to the actual login page. Any suggestions on how to skip the loading of the instructions page altogether will be much appreciated.

Note: grep -R alone is a significant reason why Linux- and Unix-based OS's (e.g., Mac) are so much better for developers than Windows, out of the box.

Saturday, November 5, 2011

JavaScript Hack to Render Red Bar for Required apex:selectList

I'm surprised that Salesforce doesn't support rendering apex:pageBlockSectionItem elements with the same red bar that identifies a required element.

All I wanted was for ...


... to look like ...


So, for consistency of developing a Visualforce page that has a consistent look-and-feel, I came up with a script snippet that seems to work to add the red bar to any apex:pageBlockSectionItem with the dataStyleClass set to "requiredData".

Here's the code:
/**
 * Add the Salesforce "required" appearance to an 
 * input cell.
 *
 * @param td The input cell to give a "required" 
 *           appearance.
 */
function addRequiredAppearance(td) {
    
    // Construct the wrapper div that goes inside 
    // the td.
    
    var requiredInputDiv = 
            document.createElement("div");

    requiredInputDiv.setAttribute(
            "class", "requiredInput");
    
    // Construct and append the div that renders 
    // as the red bar.
    
    var requiredBlockDiv = 
            document.createElement("div");

    requiredBlockDiv.setAttribute(
            "class", "requiredBlock");

    requiredInputDiv.appendChild(
            requiredBlockDiv);
    
    // Move each child from the td inside the 
    // wrapper div.
    
    while (td.firstChild) {
        requiredInputDiv.appendChild(
                td.removeChild(td.firstChild));
    }   // while (td.firstChild)
    
    // Append the wrapper div inside the td.
    
    td.appendChild(requiredInputDiv);
}   // function addRequiredAppearance(td)

// Iterate through every marked element to add 
// the required appearance.

jQuery(".requiredData").each(function (i) {
    addRequiredAppearance(this);
});

With the desired apex:pageBlockSectionItem elements marked, this code adds the red bar to compliment a Visualforce input element that has the required attribute set to "true".

As mentioned in the discussion thread, Salesforce may at any time change the way they render required fields. Since this was only tested in Winter '12, the hack may not work in a later release if applied as-is. However, the concept should still hold true, and as long as the function is modified appropriately all should be well.

Note: This hack uses the jQuery library for selecting marked elements.

Thursday, October 13, 2011

JavaScript Hack to Disable Fields for Internal WebCenter Users

In ApplyYourself, it may sometimes be desirable for some application fields to be editable by the applicant and then locked down for internal WebCenter users after the application is submitted. One example may be the term to which the applicant originally applied, before a decision or subsequent deferral occurs.

In order to accomplish this, the following JavaScript hack may be used.

<script type="text/javascript">
function isViewedInWebCenter() {
  return document.domain == "webcenter.applyyourself.com";
} // function isViewedInWebCenter()

if (isViewedInWebCenter()) {
  var inputElement =
      document.getElementById(inputElementId);
  inputElement.disabled = true;
} // if (isViewedInWebCenter())
</script>

Adding this bit of code to the bottom of a section's HTML should do the trick.

Friday, May 27, 2011

JavaScript Hack to Add All Fields to Export Template

Faced with the daunting task of creating an export template in ApplyYourself that included all available fields, I decided to try my luck at using JavaScript to do the job for me (with greater accuracy).

The end result is the following hack, which adds all exposed nodes to the template.
javascript:

/* Grab the fields frame. */

var fieldsFrame =
    document.getElementsByName(
        "frameQuestionsTree")[0];
var fieldsWindow = fieldsFrame.contentWindow;
var fieldsDocument = fieldsWindow.document;

/* Grab the actions frame. */

var actionsFrame =
    document.getElementsByName(
        "frameActions")[0];
var actionsWindow = actionsFrame.contentWindow;
var actionsDocument = actionsWindow.document;

/* Find the exposed nodes to add. */

var fieldsATags = fieldsDocument.getElementsByTagName("a");
alert(fieldsATags.length + " A tags found in fields window.");

var nodeIdPattern = /Nod[0-9]+/;
var nodeATags = new Array();
for (var i = 0; i < fieldsATags.length; i++) {
  var fieldsAElem = fieldsATags[i];
  var fieldsAIdAttr = fieldsAElem.attributes["id"];
  if (fieldsAIdAttr) {
    if (fieldsAIdAttr.value.match(nodeIdPattern)) {
      var nodeNumText = fieldsAIdAttr.value.slice(3);
      fieldsWindow.setSelectedNode(parseInt(nodeNumText));
      actionsWindow.BtnAddField_onclick();
    }
  }
}
This hack was tested in...
  • Chrome 11 on Windows 7
  • Internet Explorer 9 on Windows 7

Tuesday, May 24, 2011

JavaScript Hack to Set Visibility for Field-Level Security

Having to click numerous (sometimes over 100) checkboxes just to grant or revoke visibility to certain fields via Field-Level Security settings can be a pain. Here's a JavaScript hack that can mark all of the "Visible" checkboxes on the Field-Level Security edit page.

The following code was tested in Firefox 4 and Chrome 11 on Windows 7. It can probably be adapted easily to work for marking the read-only checkbox and for clearing checkboxes as well.

javascript:

/* Locate the form. */

var flsForm =
    document.getElementById("editPage");

/* Find the form inputs. */

var inputs =
    document.getElementsByTagName("input");

var visibleInputs = new Array();
for(var i = 0; i < inputs.length; i++) {
  var titleAttr = inputs[i].attributes["title"];
  if(titleAttr != null) {
    if(titleAttr.value == "Visible") {
      var visibleInput = inputs[i];
      visibleInputs[visibleInputs.length] =
          visibleInput;
    }
  }
}

/* Mark all checkboxes. */

for(var i = 0; i < visibleInputs.length; i++) {
  var eName =
      visibleInputs[i].attributes["name"].value;
  
  var e = flsForm.elements[eName];
  
  if(!e.checked)
    e.click();
}

Wednesday, May 18, 2011

JavaScript Hack to Mass Delete Custom Picklist Values

As an extension of last night's efforts, I've created what appears to be a working JavaScript hack to delete all picklist values from a custom picklist. This simplifies maintenance of picklist values by allowing an admin to delete all the values and then simply re-add the ones that are desired.

The following code was tested in Chrome 11 on Windows 7.

javascript:

/* Gather all of the a elements on the page. */

var links = document.getElementsByTagName("a");

/* Pick out the Del links. */

var delLinks = new Array();
for (var i = 0; i < links.length; i++) {
  var link = links[i];
  
  if (link.innerHTML == "Del") {
    /*alert("Del link found!");*/
    /*alert(link.attributes['href'].value);*/
    delLinks[delLinks.length] = link;
  }
}

/* Open each Del link to delete the associated
   picklist value.
   
   This code can be augmented as desired
   to only delete certain values.
   
   However, for custom picklists it's probably
   easier to just delete all of the values
   and then re-add the desired values. */

for (var i = 0; i < delLinks.length; i++) {
  var delLink = delLinks[i];
  window.open(
      delLink.attributes['href'].value);
}

As with all hacks, please to use with caution, at your own risk.