Thoughts on UI Manipulation

[Josh Kenzer]

All,

I have a client where the finance associate receives credit card statements and wants to import them into purchasing with limited data. She then assigns out to the credit card holder to update line items by adding dimensions. However, in the Intacct UI, when you change some of the dimensions on the entry, it zero's out the price. In order to make this process more streamlined, I created this script to save the original pricing and revert it back if it's changed.

What are your thoughts on manipulation of the core UI this way? One downside is if the CSS of the entries table changes, the code will break. I do think I used minimal selectors and if there is a UI refresh, it should be quick to fix. Other thoughts. Is this a really bad idea?

let observers = []; // Keep track of observers to avoid duplicates

// Monitor all fields in the table for changes
let allFields = jq("#table__obj__ENTRIES .form-control");

allFields.change(function () {
  savePrices(); // Trigger savePrices on any field change
});

function savePrices() {
  let priceFields = jq("#table__obj__ENTRIES .form-control")
    .filter(function () { 
      return this.id.match(/_obj__ENTRIES_(\d+)_-_obj__UIPRICE/); // Match price fields
    });

  // Attach MutationObserver to each price field
  priceFields.each(function (i, field) {
    let initialValue = jq(field).val(); // Capture the initial value of the price field

    // Check if an observer is already set for this field
    if (observers.includes(field)) return;

    // MutationObserver fallback for tracking changes via JavaScript
    let observer = new MutationObserver(function (mutations) {
      mutations.forEach(function (mutation) {
        if (mutation.type === "attributes" && mutation.attributeName === "value") {
          // Restore the initial value if the price field's value changes
          jq(field).val(initialValue);
        }
      });
    });

    // Observe changes to the 'value' attribute of the price field
    observer.observe(field, {
      attributes: true,
      attributeOldValue: true,
      attributeFilter: ["value"]
    });

    // Store observer to avoid duplicate observers on the same field
    observers.push(field);

    // Fallback: Periodically ensure the value is unchanged (for direct JS updates)
    setInterval(function () {
      if (jq(field).val() !== initialValue) {
        jq(field).val(initialValue);
      }
    }, 500); // Adjust the interval as needed
  });
}

// Initialize the MutationObserver when the page loads or fields are dynamically added
jq(document).ready(function () {
  savePrices(); // Set up observers for existing price fields on page load
});

 

[Lindsay Klatzkin]

We do a LOT of UI manipulation with some of our customizations.  Like what you're doing here, we try to keep it as generic as possible.  I believe the risk is just assumed to be ours and that we'll be responsible for checking it after each Intacct update.

[Lee Savidge]

My understanding of page scripting like this is that it should be done as a last resort. That said, sometimes it is your only option and I don't see an issue with doing this. I've written serveral page scripts that alter the UI. The downside is that a future upgrade could break it and you just have to take that on the chin and fix it when it breaks. Wherever I use them myself, I always let the customer know that future upgrades to the UI may break it and we will do our best to fix it quickly. We do have access to upgrades before general release so we can test things and fix them before the UI is upgraded.