New concept "Extensions"

In the latest version (25.5.9), I’m adding Extensions. I know we had previously extensions for injecting javascript. But that got messy real quick.

New extensions are about injecting iframes. See: https://extensions.manager.io

I have created sample extension which is available at https://extensions.manager.io/example

End users would not go this URL directly. Instead, they would set it up as extension under Settings tab.

There are just 3 fields:

  • Name: name of extension
  • Endpoint: URL of extension which will point to some HTML page
  • Placement: this is relative URL within Manager.io where this extension should be injected. In my example, I’m using URL of Bank and Cash Accounts tab.

Once this extension is created, when I navigate to Bank and Cash Accounts tab. I will see:

Notice Example extension box below.

When I click the box. The extension will unfold and show the content of HTML page of extension.

HTML page will receive context which will include API endpoint and API access token which you can then use to make API queries.

This is better than Relay because user will not be redirected to another page. They will stay within Manager making everything more seamless.

Also this is more flexible because IFRAME can be injected to any screen.

I’m thinking that bank feeds, e-invoicing, country-specific reports and even POS systems can be all implemented within iframes.

Yes this link will be useful. I ll give a try. And my kind request don’t remove Relay, becoz, for E-Invoicing I really need that.

I will also test it out within this coming week and I will feedback if I encounter any issues.

I am planning to migrate my eInvoicing service application from Relay to a Manager Extension.
However, I feel that displaying an Extension only inside an embedded page is less flexible for users.

My Extension uses almost a full page to display data, and I believe showing it in a floating window would provide a much better user experience compared to being embedded.

If possible, I would like to propose adding an option to open Extensions in an iframe as a floating window (draggable/resizable). For example, by adding a new button/dropdown-menu next to the Relay button or replacing the Relay button.

Extension starts at 150px height and 100% width.

From your extension, you can make your extension have 500px height:

window.parent.postMessage({ type: "resize", height: 500 }, "*");

Typically you would just send it your scrollHeight

window.parent.postMessage({ type: "resize", height: document.documentElement.scrollHeight }, "*");

But I’m thinking that I could use dialog element to show iframe. That would avoid these resizing calls. dialog would simply give you all the space. So extension would be a button. You click it, and dialog shows with your iframe within it.

OK, let me experiment with this. I think your idea is universally better for user experience.

I would also like to propose providing a postMessage API on each Manager page/tab to expose the currently active URL, especially on the Customer, Supplier, Sales Invoice, and Credit Note tabs.
This would allow an Extension to determine exactly where it is running inside Manager.

As a real use case, I’ve added an invoicing feature for Malaysia, where the requirement is to create full Customer/Supplier records directly from the Taxpayer QR Code. To ensure that the data saved in Manager business data matches the official data stored on the tax authority’s server.

Knowing the current active page is very important.

It would be very helpful for determining where the data should be recorded in Manager, or what data needs to be retrieved from Manager, depending on which tab is currently active.

This capability would also help anyone building Extensions for exporting or importing data to/from Manager, since the Extension could easily detect where it is opened and what data should be read or processed in that tab.

You can already do that:

Request the current page context to confirm the user is viewing an invoice:

window.parent.postMessage({ "type": "page-request" }, "*");

Expected response example:

{
  "type": "page-response",
  "body": {
    "handler": "SalesInvoiceView",
    "query": {
      "key": "<INVOICE_KEY>"
    }
  }
}

Basically page-request will reveal path and query for the current document.

Yes, this works on the Invoice view, but it does not work on the Customers tab or Supplier tab.

I got it working.
Previously I was trying to catch the active page using context-response, but that was wrong. The correct way is to listen for page-response.

Page Context diterima: {
  "handler": "Customers",
  "query": {
    "fileID": "InvoiceEGS 1.1"
  }
}

In the latest version I made it so each extension is a button which will open iframe in modal dialog window. I think this will improve user experience as it will put your extension content into focus.

It won’t be resizable as it will already take nearly all available space except for inset so the user is able to click back to Manager.

Right now I’ll leave it at the bottom as extensions can be on any screen so whatever placement extensions will have, it will need to be universal position.

This is for desktop edition only for now. Just to test things out.

Is there a way to control the size of modals or floating windows via postMessage?

If not, we would like to request an option in Manager to configure a preferred modal size through the extension settings. Currently, automatic resizing with sendResize is not working, so having a user-defined default modal size would greatly improve usability and consistency of embedded pages.

Can you show screenshot what you currently see? The idea is that Manager will simply set width and height of dialog automatically to 100% minus some offset so the user can click outside of dialog to close it. There is no need to sendResize because dialog will be set to be at maximum automatically. If they need even more space than that, scrollbar will appear.

Request: More Flexible Modals for Extensions

Currently, extension pages inside modals feel cramped and inflexible. Ideally, the content inside a modal should behave just like a normal page.
We would like modals in Manager to support:

  1. Preferred size (default width & height, e.g., 80% of viewport)
  2. Resizable modal (user can drag to resize)
  3. Responsive layouts inside the iframe (so the page adapts like in a full browser tab)

This would make using modals feel the same as opening a regular page, while keeping the convenience of a modal.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Resizable Modal with Iframe</title>
  <style>
    body {
      font-family: Arial, sans-serif;
      margin: 0;
      padding: 20px;
    }

    .modal-backdrop {
      display: none;
      position: fixed;
      top: 0; left: 0;
      width: 100%; height: 100%;
      background: rgba(0,0,0,0.5);
      justify-content: center;
      align-items: center;
      z-index: 1000;
    }

    .modal {
      background: #fff;
      border-radius: 8px;
      display: flex;
      flex-direction: column;
      width: 80%;       /* Preferred size */
      height: 80%;      /* Preferred size */
      max-width: 95%;
      max-height: 95%;
      min-width: 300px;
      min-height: 200px;
      box-shadow: 0 0 20px rgba(0,0,0,0.3);

      resize: both;
      overflow: hidden;
      position: relative;
    }

    .modal-header {
      padding: 10px;
      background: #007bff;
      color: white;
      display: flex;
      justify-content: space-between;
      align-items: center;
    }

    .modal-body {
      flex: 1;
      overflow: hidden;
    }

    .modal-body iframe {
      width: 100%;
      height: 100%;
      border: none;
    }

    .close-btn {
      cursor: pointer;
      background: none;
      border: none;
      color: white;
      font-size: 18px;
    }
  </style>
</head>
<body>

  <h1>Sample Page</h1>
  <button id="openModal">Open Resizable Modal</button>

  <!-- Modal -->
  <div class="modal-backdrop" id="modalBackdrop">
    <div class="modal" id="modalWindow">
      <div class="modal-header">
        <span>Resizable Iframe Modal</span>
        <button class="close-btn" id="closeModal">&times;</button>
      </div>
      <div class="modal-body">
        <iframe src="https://manager.io"></iframe>
      </div>
    </div>
  </div>

  <script>
    const modalBackdrop = document.getElementById("modalBackdrop");
    const openModalBtn = document.getElementById("openModal");
    const closeModalBtn = document.getElementById("closeModal");

    openModalBtn.addEventListener("click", () => {
      modalBackdrop.style.display = "flex"; 
    });

    closeModalBtn.addEventListener("click", () => {
      modalBackdrop.style.display = "none"; 
    });

    // ❌ Hapus fitur tutup dengan klik backdrop
    // Jadi sekarang hanya tombol close yang bisa menutup modal
  </script>
</body>
</html>

I’m reluctant to implement resizing and moving at this point. However the latest version is now giving you full height minus offset so it looks like kind of like on your test page.

That’s fine, resizing and moving is not essential.
But at least the scrolling issue could be improved.

Ideally, the modal should not display scrollbars until the iframe content actually reaches its minimum width or minimum height.

Right now, the scrollbars appear too early (see screenshot below). In my sample HTML page, scrollbars only show when necessary, which makes the modal feel more like a normal responsive page.

Maybe you could try applying the CSS from my sample modal as a reference.

I just tried again, and this time the modal works fine.
The scrollbar issue I mentioned earlier is no longer happening. :+1:

Is it possible to place a single extension across multiple pages (multi-placement)?

Currently, we need to register separate instances of the same extension for each page, such as customers, suppliers, sales-invoice-view, and credit-note-view even though they all use the same extension URL.

It would be much more efficient if one extension could be applied to multiple pages at once, avoiding repetitive configuration.

I agree. This is something I need for theme enhancer extension too. I’m planning to add this ability very soon.