<?xml version="1.0" encoding="utf-8"?>

<feed xmlns="http://www.w3.org/2005/Atom">
  <title>CloudScript.io News</title>
  <subtitle>Release announcements and company news from CloudScript.io.</subtitle>
  <id>https://www.cloudscript.io/news/</id>
  <link href="https://www.cloudscript.io/news/"/>
  <link rel="self" type="application/atom+xml" href="https://www.cloudscript.io/news/feed.xml"/>
  <updated>2026-10-08T00:00:00+00:00</updated>
  <author><name>CloudScript.io</name></author>

  <entry>
    <title>MSG/EML Email Viewer for Jira: read the attached email on the issue</title>
    <id>https://www.cloudscript.io/news/email-viewer-jira-2-0</id>
    <link href="https://www.cloudscript.io/news/email-viewer-jira-2-0"/>
    <published>2026-10-08T00:00:00+00:00</published>
    <updated>2026-10-08T00:00:00+00:00</updated>
    <category term="email-viewer-jira" label="MSG/EML Email Viewer for Jira"/>
    <summary>MSG/EML Email Viewer for Jira, new on the Atlassian Marketplace, renders the .msg and .eml files attached to a Jira issue as email cards in an Emails tab, read from your own Jira as you and parsed in your browser.</summary>
    <content type="html" xml:base="https://www.cloudscript.io/news/email-viewer-jira-2-0">&lt;p&gt;MSG/EML Email Viewer for Jira is now live on the &lt;a href=&quot;https://marketplace.atlassian.com/apps/463039643/msg-eml-email-viewer-for-jira&quot;&gt;Atlassian Marketplace&lt;/a&gt;. An email attached to a Jira issue is frequently the record of what was agreed, whether a client’s instruction or the correspondence behind a support request, and until now it has been a download link: reading it meant saving the file and opening it in a mail application. This app renders every .msg and .eml file attached to an issue in place, as the person viewing it and under Jira’s own permissions, so the attached original can be read where it was filed.&lt;/p&gt;

&lt;h2 id=&quot;the-emails-tab&quot;&gt;The Emails tab&lt;/h2&gt;

&lt;p&gt;The Emails tab appears on every issue in every project from the moment the app is installed, with nothing to configure. It lists each attached email as a card showing the subject, sender, recipients, date and body, with inline images in place and the email’s own attachments shown as tiles. Where a message cannot be rendered in full, the card states the reason rather than silently omitting data. Each tile offers a download and an Attach to work item action: one click attaches the file from inside the email to the issue as an ordinary Jira attachment, or all of them at once, so a document that arrived inside an email becomes an attachment in its own right without being downloaded and uploaded again.&lt;/p&gt;

&lt;h2 id=&quot;counted-and-listed-in-the-sidebar&quot;&gt;Counted and listed in the sidebar&lt;/h2&gt;

&lt;p&gt;The issue’s right-hand column gains an Attached emails group. It reads “3 emails attached:” above an index that names each file with the date it was attached and who attached it, followed by a pointer to the Emails tab. The dates agree with Jira’s own attachments panel to the instant and the time zone and differ only in format.&lt;/p&gt;

&lt;h2 id=&quot;jira-service-management&quot;&gt;Jira Service Management&lt;/h2&gt;

&lt;p&gt;In Jira Service Management the app is for agents and other internal users. The Emails tab is in the issue’s Activity section, and rendered emails are not visible to customers using the portal. An email attached to an internal note is visible to the same people who can see the attachment itself, because every call the app makes runs as the viewing user.&lt;/p&gt;

&lt;h2 id=&quot;permissions-and-data-handling&quot;&gt;Permissions and data handling&lt;/h2&gt;

&lt;p&gt;The app requests eleven granular Jira permissions: ten reads, and one write that is used only when you click Attach. Every call runs as the viewing user, so Jira’s permissions decide what renders. Files are read from your own Jira and parsed in your browser, only the first 1,024 bytes of each are read on Atlassian-hosted compute to classify its format, then discarded. Nothing is stored, apart from a file you choose to attach, which becomes an ordinary attachment on the issue in your own Jira, and no email content reaches Cloudscript. The app operates no server and holds no store of its own, which is what the Runs on Atlassian badge on the listing attests. The &lt;a href=&quot;/apps/email-viewer-jira/privacy&quot;&gt;privacy policy&lt;/a&gt;, &lt;a href=&quot;/apps/email-viewer-jira/terms&quot;&gt;terms&lt;/a&gt; and a &lt;a href=&quot;/apps/email-viewer-jira/dpa&quot;&gt;data processing agreement&lt;/a&gt; are published alongside the guide.&lt;/p&gt;

&lt;p&gt;The app joins &lt;a href=&quot;/apps/email-viewer&quot;&gt;MSG/EML Email Viewer for Confluence&lt;/a&gt;, released in September, which renders the same file formats on Confluence pages. The two apps are listed and licensed separately.&lt;/p&gt;

&lt;p&gt;Read more in our &lt;a href=&quot;/apps/email-viewer-jira&quot;&gt;User guide&lt;/a&gt;.&lt;/p&gt;
</content>
  </entry>

  <entry>
    <title>Mermaid Diagrams 2.9: Mermaid 12 and a front matter editor</title>
    <id>https://www.cloudscript.io/news/mermaid-2-9</id>
    <link href="https://www.cloudscript.io/news/mermaid-2-9"/>
    <published>2026-10-04T00:00:00+00:00</published>
    <updated>2026-10-04T00:00:00+00:00</updated>
    <category term="mermaid" label="CloudScript Mermaid Diagrams for Confluence"/>
    <summary>Version 2.9 of CloudScript Mermaid Diagrams for Confluence adds Mermaid 12 alongside Mermaid 11, chosen separately for each diagram, and a visual editor for a diagram&apos;s title, theme, look and layout.</summary>
    <content type="html" xml:base="https://www.cloudscript.io/news/mermaid-2-9">&lt;p&gt;Version 2.9 of CloudScript Mermaid Diagrams for Confluence is now live on the &lt;a href=&quot;https://marketplace.atlassian.com/apps/1219878/cloudscript-mermaid-diagrams-for-confluence&quot;&gt;Atlassian Marketplace&lt;/a&gt;. The release adds Mermaid 12 support, while retaining support for Mermaid 11 in the app, allowing a Mermaid version to be recorded for each diagram. As a result, your existing diagrams created with Mermaid 11 continue to display after the update, and moving a diagram to the newer Mermaid version is a decision made one diagram at a time. The macro’s configuration panel also gains a visual editor for easier configuration of settings that previously had to be written by hand as YAML at the top of the diagram.&lt;/p&gt;

&lt;style&gt;
  .prose figure.shot { margin: 1.6rem 0; }
  .prose figure.shot img { width: 100%; display: block; border: 1px solid #E4EAF1; border-radius: 12px; background: #FFFFFF; }
  .prose figure.shot figcaption { font-size: 0.85rem; color: #5C6B7E; margin-top: 0.5rem; text-align: center; }
&lt;/style&gt;

&lt;h2 id=&quot;mermaid-12-one-diagram-at-a-time&quot;&gt;Mermaid 12, one diagram at a time&lt;/h2&gt;

&lt;p&gt;The app now includes Mermaid 12 (12.1.0 in this release) alongside Mermaid 11 (11.15.0), and a new Version setting in the configuration panel chooses between them for each macro. New diagrams start on Mermaid 12. Every diagram created before this release stays on Mermaid 11 until someone opens its configuration panel and changes Version, and it can be changed back in the same way.&lt;/p&gt;

&lt;p&gt;We kept both versions because Mermaid 12 does not draw every diagram the way Mermaid 11 did. A flowchart with no theme set, for example, renders in Mermaid 12’s newer default style and with different spacing. Upgrading every diagram automatically would therefore have changed the appearance of published pages that nobody had edited. A page only downloads the Mermaid versions its diagrams use.&lt;/p&gt;

&lt;figure class=&quot;shot&quot;&gt;
  &lt;img src=&quot;/apps/mermaid/guide-mermaid-11-and-12.png&quot; alt=&quot;A Confluence page with the same release pipeline flowchart drawn twice: by Mermaid 11 with purple filled nodes and thin connectors, and by Mermaid 12 with white outlined nodes and heavier, squared connectors.&quot; width=&quot;1840&quot; height=&quot;900&quot; loading=&quot;lazy&quot; /&gt;
  &lt;figcaption&gt;The same flowchart drawn by Mermaid 11 with the Classic look and by Mermaid 12 with the Neo look.&lt;/figcaption&gt;
&lt;/figure&gt;

&lt;p&gt;Mermaid 12 also adds diagram types that Mermaid 11 does not have. Swimlane diagrams (&lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;swimlane-beta&lt;/code&gt;) are one example: they render on Mermaid 12 and report a diagram error if Mermaid 11 is selected for the diagram.&lt;/p&gt;

&lt;h2 id=&quot;a-visual-editor-for-front-matter&quot;&gt;A visual editor for front matter&lt;/h2&gt;

&lt;p&gt;Mermaid reads a diagram’s title, theme, look and layout from its front matter, the block of YAML between two &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;---&lt;/code&gt; lines at the top of the source. Until now those settings had to be typed as code. The configuration panel now has Title, Theme, Look and Layout controls underneath the source box, and they stay in step with the text: changing a control writes the setting into the front matter, and editing the front matter by hand updates the controls. Front matter settings and comments that the editor does not manage are left as they were written.&lt;/p&gt;

&lt;figure class=&quot;shot&quot;&gt;
  &lt;img src=&quot;/apps/mermaid/share-editor-redux-colour.png&quot; alt=&quot;The Mermaid diagram configuration panel beside its result: flowchart source with front matter setting the theme, look and layout, the Title, Theme, Look, Layout and Version controls set to Redux colour, Neo, ELK and Mermaid 12, and the rendered order-processing flowchart.&quot; width=&quot;1840&quot; height=&quot;900&quot; loading=&quot;lazy&quot; /&gt;
  &lt;figcaption&gt;The configuration panel and the diagram it produces. The Theme, Look and Layout controls match the front matter at the top of the source.&lt;/figcaption&gt;
&lt;/figure&gt;

&lt;p&gt;The Theme list grows from four options to twelve, adding the Neo and Redux families and a Custom colours theme with fill, border, text and line colours. Look offers Classic, Hand-drawn and Neo. Layout offers ELK, which previously had to be written into the front matter by hand. Each of the three also has an Automatic option that leaves the setting out, so Mermaid chooses what suits the diagram type. Every theme and look works with both Mermaid versions.&lt;/p&gt;

&lt;h2 id=&quot;what-has-not-changed&quot;&gt;What has not changed&lt;/h2&gt;

&lt;p&gt;This release makes no change to the app’s permissions or data handling. Each diagram is still drawn in the reader’s browser from the source stored in the macro on your Confluence page, and nothing is sent outside Atlassian. Existing installations update automatically and no administrator action is needed. Diagrams are still included in Confluence’s Export to PDF, and Export to Word is not yet available.&lt;/p&gt;

&lt;p&gt;Read more in our updated &lt;a href=&quot;/apps/mermaid&quot;&gt;User guide&lt;/a&gt;.&lt;/p&gt;
</content>
  </entry>

  <entry>
    <title>Tech Adoption Radar 2.5: build a radar in a table</title>
    <id>https://www.cloudscript.io/news/radar-renderer-2-5</id>
    <link href="https://www.cloudscript.io/news/radar-renderer-2-5"/>
    <published>2026-09-07T00:00:00+00:00</published>
    <updated>2026-09-07T00:00:00+00:00</updated>
    <category term="radar-renderer" label="Tech Adoption Radar for Confluence"/>
    <summary>Version 2.5 of Tech Adoption Radar for Confluence adds a Table View to the macro editor, a numbered legend on downloaded images, and clearer handling of crowded quadrants.</summary>
    <content type="html" xml:base="https://www.cloudscript.io/news/radar-renderer-2-5">&lt;p&gt;Version 2.5 of Tech Adoption Radar for Confluence is now live on the &lt;a href=&quot;https://marketplace.atlassian.com/apps/2543668212/tech-adoption-radar-for-confluence&quot;&gt;Atlassian Marketplace&lt;/a&gt;. The release changes how a radar is authored: until now the macro took its blip list as a block of CSV or radar.js JSON text, which suited people who already kept their radar in a file and left everyone else assembling one first. The macro editor now opens in a Table View, where a radar can be built without leaving Confluence.&lt;/p&gt;

&lt;h2 id=&quot;table-view&quot;&gt;Table View&lt;/h2&gt;

&lt;p&gt;In Table View each blip is a row with its name, ring, quadrant and movement, and a row expands to hold a description and a link. Rows can be typed in one at a time, pasted straight from a spreadsheet (the editor recognises the paste and reports how many rows it added, flagging any ring or quadrant value it does not recognise), or loaded by uploading a CSV or JSON file. The table enforces the 400-blip ceiling as data is entered, and a paste or upload that exceeds it is truncated to the first 400 rows with a warning naming the number discarded.&lt;/p&gt;

&lt;p&gt;The previous editor is still there as Text View, one click away, for anyone who prefers to paste CSV or radar.js JSON directly. Both views read and write the same stored source, so a radar built in one can be edited in the other, and macros inserted with earlier versions keep rendering and editing exactly as before.&lt;/p&gt;

&lt;h2 id=&quot;images-that-read-on-their-own&quot;&gt;Images that read on their own&lt;/h2&gt;

&lt;p&gt;A radar downloaded as an image now carries the numbered legend beneath the chart, grouped by quadrant and ring, so the picture can be dropped into a slide or a document without the page it came from.&lt;/p&gt;

&lt;h2 id=&quot;crowded-quadrants-and-accessibility&quot;&gt;Crowded quadrants and accessibility&lt;/h2&gt;

&lt;p&gt;Below the 400-blip limit a quadrant can still hold more blips than can be drawn without overlap. The radar provides a detailed warning when some items cannot be displayed, while retaining these blips in the numbered legend beneath the chart. The release also includes accessibility fixes to the authoring surface, including a live blip count that screen readers announce as rows are added.&lt;/p&gt;

&lt;h2 id=&quot;what-has-not-changed&quot;&gt;What has not changed&lt;/h2&gt;

&lt;p&gt;The app still requests no permissions and sends nothing outside Atlassian: the blip list is stored in the macro on your page and the chart is drawn in the reader’s browser. This release makes no change to the app’s scopes or data handling, so existing installations update automatically and no administrator action is needed.&lt;/p&gt;

&lt;p&gt;A two-minute demo of the app is on the &lt;a href=&quot;/apps/radar-renderer#demo&quot;&gt;user guide&lt;/a&gt; and on &lt;a href=&quot;https://www.youtube.com/watch?v=X9wxTSpgqzw&quot;&gt;YouTube&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;Read more in our updated &lt;a href=&quot;/apps/radar-renderer&quot;&gt;User guide&lt;/a&gt;.&lt;/p&gt;
</content>
  </entry>

  <entry>
    <title>MSG/EML Email Viewer for Confluence: read the attached email on the page</title>
    <id>https://www.cloudscript.io/news/email-viewer-2-3</id>
    <link href="https://www.cloudscript.io/news/email-viewer-2-3"/>
    <published>2026-09-02T00:00:00+00:00</published>
    <updated>2026-09-02T00:00:00+00:00</updated>
    <category term="email-viewer" label="MSG/EML Email Viewer for Confluence"/>
    <summary>MSG/EML Email Viewer for Confluence, new on the Atlassian Marketplace, renders a .msg or .eml file attached to a Confluence page as an email card, parsed in the reader&apos;s browser.</summary>
    <content type="html" xml:base="https://www.cloudscript.io/news/email-viewer-2-3">&lt;p&gt;MSG/EML Email Viewer for Confluence is now live on the &lt;a href=&quot;https://marketplace.atlassian.com/apps/2052211522/msg-eml-email-viewer-for-confluence&quot;&gt;Atlassian Marketplace&lt;/a&gt;. An email filed on a Confluence page is often the documentation itself, whether an approval, a client instruction or a piece of incident correspondence, and until now it has been a download link: reading it meant saving the file and opening it in a mail application. This macro renders the attached .msg or .eml file on the page as an email card, under the page’s own permissions, making the email contents more readily accessible to anyone who can already see the page.&lt;/p&gt;

&lt;h2 id=&quot;the-email-card&quot;&gt;The email card&lt;/h2&gt;

&lt;p&gt;The card shows the subject, sender, recipients, date and body, with inline images in place. Message attachements are displayed as tiles with a download option available for each. Setup is one screen: users can choose to display the Confluence page’s existing .msg and .eml attachments or use a drag-and-drop area to upload an email file (50 MiB attachment cap).&lt;/p&gt;

&lt;h2 id=&quot;rendered-afresh-from-your-own-confluence&quot;&gt;Rendered afresh, from your own Confluence&lt;/h2&gt;

&lt;p&gt;Your selected email file is read and parsed again on every page view, so the card shows what the attached file contains at the time of viewing. Remote images in a message body are blocked until the reader chooses to load them.  Where a message cannot be rendered in full the card displays plain english error messages describing what happened rather than silently omitting data.&lt;/p&gt;

&lt;h2 id=&quot;permissions-and-data-handling&quot;&gt;Permissions and data handling&lt;/h2&gt;

&lt;p&gt;Email files are read from your own Confluence page, remain only on Atlassian’s platform and are parsed in the reader’s browser inside the macro’s sandboxed iframe. The macro stores only the attachment’s id, its filename and an optional user-provided label. The app operates no server, has no store of its own, declares no external network destinations and holds no Forge app storage. It requests two Confluence permissions, one to read the page’s attachments and one to attach a file you upload; the &lt;a href=&quot;/apps/email-viewer/privacy&quot;&gt;privacy policy&lt;/a&gt;, &lt;a href=&quot;/apps/email-viewer/terms&quot;&gt;terms&lt;/a&gt; and a &lt;a href=&quot;/apps/email-viewer/dpa&quot;&gt;data processing agreement&lt;/a&gt; are published alongside the guide.&lt;/p&gt;

&lt;p&gt;Read more in our &lt;a href=&quot;/apps/email-viewer&quot;&gt;User guide&lt;/a&gt;.&lt;/p&gt;
</content>
  </entry>

  <entry>
    <title>NikoNiko Calendar 3.0: on Forge, with a team trend row</title>
    <id>https://www.cloudscript.io/news/nikoniko-3-0</id>
    <link href="https://www.cloudscript.io/news/nikoniko-3-0"/>
    <published>2026-08-06T00:00:00+00:00</published>
    <updated>2026-08-06T00:00:00+00:00</updated>
    <category term="nikoniko" label="NikoNiko Calendar"/>
    <summary>Version 3 moves CloudScript.io NikoNiko Calendar from Atlassian Connect to Forge and adds a team trend row, several calendars per page, and an administration screen for deleting stored entries.</summary>
    <content type="html" xml:base="https://www.cloudscript.io/news/nikoniko-3-0">&lt;p&gt;Version 3.0 of CloudScript.io NikoNiko Calendar is now live on the &lt;a href=&quot;https://marketplace.atlassian.com/apps/1223001/cloudscript-io-nikoniko-calendar&quot;&gt;Atlassian Marketplace&lt;/a&gt;. The app first shipped in mid-2020 on Atlassian Connect; version 3 rebuilds it on Atlassian Forge, so entries are now stored in Forge storage inside Atlassian’s infrastructure rather than on a server we operate. The rebuild also carries the first functional changes to the calendar in some years, each of them a response to how teams actually use a niko-niko calendar rather than a new idea about what one is.&lt;/p&gt;

&lt;h2 id=&quot;team-trend-row&quot;&gt;Team trend row&lt;/h2&gt;

&lt;p&gt;A line beneath the grid plots the team’s average entry for each day of the window. Each point is sized by the share of the team that responded that day, so a high average from two people out of nine reads differently from the same average from all nine, and the line breaks on days with no responses rather than interpolating across them. The trend row is on by default and can be switched off in the macro’s configuration.&lt;/p&gt;

&lt;h2 id=&quot;user-can-now-contribute-to-multiple--calendars&quot;&gt;User can now contribute to multiple  calendars&lt;/h2&gt;

&lt;p&gt;Entries are now isolated to the calendar in which they were recorded. This means that a user can be added to two or more calendars and record a different value on each calendar for the same day. An new optional label above each calendar can be user to specify a topic that the calendar refers to, for example a team can now publish two calendars on the same page, the first asking “How is the merge going?”, and the second asking “How is the sprint in general?” and team members provide a different answer on each calendar.  Likewise user working across multiple teams are able to provide different responses in a team calendar for each team.&lt;/p&gt;

&lt;h2 id=&quot;deleting-entries-for-better-data-management&quot;&gt;Deleting entries for better data management&lt;/h2&gt;

&lt;p&gt;All users can now delete their own entries from the entry picker. They can do this either for a single day on one calendar, or for their entire history across every calendar. Additionally, Confluence site administrators gain a Niko Niko data management screen listing every account for which the app holds entries, with the option to delete all entries for a person or all entries older than a chosen date. The accounts on the data management screen are drawn from the app’s own storage, rather than the site directory, so that administrators are able to delete data for users who have left the organisation or no longer have a Confluence account.&lt;/p&gt;

&lt;h2 id=&quot;what-has-not-changed&quot;&gt;What has not changed&lt;/h2&gt;

&lt;p&gt;Pages that already contain the macro keep rendering without reconfiguration. The calendar remains sized for a single team, with the same three-or-five-point scale and the same smiley, square and cat themes. Because the app now runs on Forge and requests granular Confluence scopes, administrators will be asked to approve the new version when it replaces the Connect app on their site; the app’s &lt;a href=&quot;/apps/nikoniko/privacy&quot;&gt;privacy policy&lt;/a&gt; describes exactly what is stored.&lt;/p&gt;

&lt;p&gt;Read more in our updated &lt;a href=&quot;/apps/nikoniko&quot;&gt;User guide&lt;/a&gt;.&lt;/p&gt;
</content>
  </entry>

  <entry>
    <title>Tech Adoption Radar for Confluence: a tech radar from a pasted blip list</title>
    <id>https://www.cloudscript.io/news/radar-renderer-2-2</id>
    <link href="https://www.cloudscript.io/news/radar-renderer-2-2"/>
    <published>2026-07-21T00:00:00+00:00</published>
    <updated>2026-07-21T00:00:00+00:00</updated>
    <category term="radar-renderer" label="Tech Adoption Radar for Confluence"/>
    <summary>Tech Adoption Radar for Confluence, new on the Atlassian Marketplace, renders a Thoughtworks-style CSV or radar.js JSON blip list as a quadrant radar directly in a Confluence Cloud page.</summary>
    <content type="html" xml:base="https://www.cloudscript.io/news/radar-renderer-2-2">&lt;p&gt;Tech Adoption Radar for Confluence is now live on the &lt;a href=&quot;https://marketplace.atlassian.com/apps/2543668212/tech-adoption-radar-for-confluence&quot;&gt;Atlassian Marketplace&lt;/a&gt;. Technology radars in the Thoughtworks style are usually built with a separate tool and pasted into Confluence as an image, which goes stale the moment a blip moves. This macro draws the radar from a blip list stored in the page, so updating the radar means editing the list.&lt;/p&gt;

&lt;h2 id=&quot;two-formats-one-radar&quot;&gt;Two formats, one radar&lt;/h2&gt;

&lt;p&gt;The macro accepts the Thoughtworks build-your-own-radar CSV convention and the Zalando radar.js JSON dialect, so an existing radar kept in either format pastes in without conversion. Each blip carries a movement marker, and a numbered legend grouped by quadrant and ring sits beneath the chart. The four quadrants can each take a colour from a curated palette of Atlassian accents, and a blip’s link opens in Confluence when it points at the same site.&lt;/p&gt;

&lt;h2 id=&quot;export-and-download&quot;&gt;Export and download&lt;/h2&gt;

&lt;p&gt;A page exported to PDF or Word carries the radar as a structured table by quadrant and ring rather than a blank space, and a Download as image button on the macro produces the chart itself, drawn client-side, for use in a slide or document.&lt;/p&gt;

&lt;h2 id=&quot;permissions-and-data-handling&quot;&gt;Permissions and data handling&lt;/h2&gt;

&lt;p&gt;The radar is drawn in the reader’s browser from the list stored in the macro. The app requests no Forge scopes, declares no egress and stores nothing beyond the page content, so there is nothing for an administrator to review beyond the install itself.&lt;/p&gt;

&lt;p&gt;Read more in our &lt;a href=&quot;/apps/radar-renderer&quot;&gt;User guide&lt;/a&gt;.&lt;/p&gt;
</content>
  </entry>

  <entry>
    <title>Cloudscript Renderer for MCP Documentation: server.json as readable Confluence pages</title>
    <id>https://www.cloudscript.io/news/mcp-renderer-2-0</id>
    <link href="https://www.cloudscript.io/news/mcp-renderer-2-0"/>
    <published>2026-07-17T00:00:00+00:00</published>
    <updated>2026-07-17T00:00:00+00:00</updated>
    <category term="mcp-renderer" label="Cloudscript Renderer for MCP Documentation"/>
    <summary>New on the Atlassian Marketplace: a Confluence macro that turns a pasted MCP Registry server.json or tools/list result into structured documentation with capability cards, parameter tables and a table of contents.</summary>
    <content type="html" xml:base="https://www.cloudscript.io/news/mcp-renderer-2-0">&lt;p&gt;Cloudscript Renderer for MCP Documentation is now live on the &lt;a href=&quot;https://marketplace.atlassian.com/apps/2358641825/cloudscript-renderer-for-mcp-documentation&quot;&gt;Atlassian Marketplace&lt;/a&gt;. Teams standing up Model Context Protocol servers, and particularly internal servers that appear in no public registry, tend to document them as a JSON dump in a code block or not at all. This macro takes that JSON as pasted and renders it as documentation on the Confluence pages developers, security reviewers and platform teams already read.&lt;/p&gt;

&lt;h2 id=&quot;what-it-renders&quot;&gt;What it renders&lt;/h2&gt;

&lt;p&gt;Paste an MCP Registry &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;server.json&lt;/code&gt; document or a &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;tools/list&lt;/code&gt; result into the macro and it detects which you pasted, accepting a bare result or one wrapped in a JSON-RPC envelope. A &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;server.json&lt;/code&gt; renders as a header with name, description and schema link, package tables with environment variables (secrets badged as such) and an install command. A &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;tools/list&lt;/code&gt; result renders as one capability card per tool, with parameter tables, annotation pills whose tooltips explain what each hint means, and a table of contents. It is purpose-built for MCP: not a generic JSON viewer, and not another MCP server product.&lt;/p&gt;

&lt;h2 id=&quot;your-code-stays-the-source-of-truth&quot;&gt;Your code stays the source of truth&lt;/h2&gt;

&lt;p&gt;The page holds the pasted JSON rather than a rendering of it, so editing the source in the macro re-renders the Confluence page and every server documents identically. The macro exports to PDF and Word as native content.&lt;/p&gt;

&lt;h2 id=&quot;permissions-and-data-handling&quot;&gt;Permissions and data handling&lt;/h2&gt;

&lt;p&gt;The app requests no Confluence or Jira scopes, declares no egress and has no app-side storage; it works only on the text pasted into its own macro configuration, which is parsed and drawn in the reader’s browser. Control characters such as bidirectional overrides are removed from the rendered text with a notice, and the stored source is left unchanged. Source is capped at 512 KiB.&lt;/p&gt;

&lt;p&gt;Read more in our &lt;a href=&quot;/apps/mcp-renderer&quot;&gt;User guide&lt;/a&gt;.&lt;/p&gt;
</content>
  </entry>

  <entry>
    <title>Cloudscript Typst Renderer: Typst documents and mathematics on the page</title>
    <id>https://www.cloudscript.io/news/typst-renderer-2-5</id>
    <link href="https://www.cloudscript.io/news/typst-renderer-2-5"/>
    <published>2026-07-15T00:00:00+00:00</published>
    <updated>2026-07-15T00:00:00+00:00</updated>
    <category term="typst-renderer" label="Cloudscript Typst Renderer"/>
    <summary>Cloudscript Typst Renderer, new on the Atlassian Marketplace, compiles Typst source in the reader&apos;s browser and renders documents and mathematics directly on a Confluence Cloud page.</summary>
    <content type="html" xml:base="https://www.cloudscript.io/news/typst-renderer-2-5">&lt;p&gt;Cloudscript Typst Renderer is now live on the &lt;a href=&quot;https://marketplace.atlassian.com/apps/1871294913/cloudscript-typst-renderer&quot;&gt;Atlassian Marketplace&lt;/a&gt;. Teams that need mathematics in Confluence commonly maintain a LaTeX-and-screenshot workflow, in which a formula is typeset elsewhere and pasted in as an image that nobody can edit or search. This macro replaces the screenshot with source: paste Typst into the macro, and the document is compiled and drawn on the page each time it is viewed, so an edit to the source is what the next reader sees.&lt;/p&gt;

&lt;h2 id=&quot;what-renders&quot;&gt;What renders&lt;/h2&gt;

&lt;p&gt;Typst covers the same ground as LaTeX, and the macro renders the full document rather than formulas alone: headings, prose, tables and code blocks alongside mathematics set in Typst’s own maths font as vector output that can be selected and zoomed. The bundled sample shows the Cauchy-Schwarz inequality, a Gaussian integral, a matrix and Maxwell’s equations on one page with prose and a highlighted code block. The macro is found by typing /typst in the editor, and the macro browser also returns it for “latex”, “math”, “equation” and “typesetting”.&lt;/p&gt;

&lt;h2 id=&quot;compiled-in-the-browser&quot;&gt;Compiled in the browser&lt;/h2&gt;

&lt;p&gt;The Typst compiler runs as WebAssembly in the reader’s browser rather than on a server, so your data is never sent to Cloudscript or to any third party. As such, the app requests no Confluence scopes, declares no egress and stores nothing outside the macro on your page; its one content-security directive exists solely to instantiate the WebAssembly module.&lt;/p&gt;

&lt;h2 id=&quot;limits&quot;&gt;Limits&lt;/h2&gt;

&lt;p&gt;The above security posture means a page exported to PDF or Word cannot carry the rendered output, since rendering happens on the live page; the export carries the Typst source in a captioned code block instead. This first release renders self-contained documents only, without package imports (&lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;@preview&lt;/code&gt;), &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;image()&lt;/code&gt; or &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;#include&lt;/code&gt;, and caps source at 64 KiB with a 10-second compile budget, which a size meter in the editor tracks as you paste. The app is an independent integration, not affiliated with or endorsed by Typst, and bundles typst.ts and the Typst fonts under their open licences.&lt;/p&gt;

&lt;p&gt;Read more in our &lt;a href=&quot;/apps/typst-renderer&quot;&gt;User guide&lt;/a&gt;.&lt;/p&gt;
</content>
  </entry>

  <entry>
    <title>Page Sharing for Confluence: read-only pages across Confluence Cloud sites</title>
    <id>https://www.cloudscript.io/news/page-sharing-4-0</id>
    <link href="https://www.cloudscript.io/news/page-sharing-4-0"/>
    <published>2026-07-06T00:00:00+00:00</published>
    <updated>2026-07-06T00:00:00+00:00</updated>
    <category term="page-sharing" label="Page Sharing for Confluence"/>
    <summary>Page Sharing for Confluence, new on the Atlassian Marketplace, delivers a page from one Confluence Cloud site to another as a native, read-only replica that follows every publish of the original.</summary>
    <content type="html" xml:base="https://www.cloudscript.io/news/page-sharing-4-0">&lt;p&gt;Page Sharing for Confluence is now live on the &lt;a href=&quot;https://marketplace.atlassian.com/apps/3283173088/page-sharing-for-confluence&quot;&gt;Atlassian Marketplace&lt;/a&gt;. It addresses a gap that consultancies, suppliers and their clients usually fill with exported PDFs or guest accounts: a page maintained on one Confluence Cloud site can be delivered to another site as a real, read-only Confluence page in the recipient’s own page tree, refreshed each time the publisher edits the original. When the engagement ends, the publisher withdraws sharing and the replicas are removed.&lt;/p&gt;

&lt;h2 id=&quot;how-a-page-is-shared&quot;&gt;How a page is shared&lt;/h2&gt;

&lt;p&gt;An editor shares a page from its menu and receives a reusable subscription link. On the receiving site, a user subscribes by pasting that link, and the page appears as a replica marked with a byline naming its source. Sharing works in both directions once the app is installed on both sites, and every subscription is revocable by the publisher.&lt;/p&gt;

&lt;h2 id=&quot;admin-control-at-both-ends&quot;&gt;Admin control at both ends&lt;/h2&gt;

&lt;p&gt;Sharing is admin-approved: a Confluence administrator on the publishing site enables sharing space by space and maintains an allow-list of partner sites, and a subscribe request from a site not yet on the list lands as pending for approval. Both checks are repeated on every push, so a partner removed from the allow-list stops receiving updates immediately.&lt;/p&gt;

&lt;h2 id=&quot;what-leaves-your-site&quot;&gt;What leaves your site&lt;/h2&gt;

&lt;p&gt;Replicas carry native content only: text, headings, lists, tables, code blocks and links. Images, attachments and macros are stripped before anything leaves the publishing site, a deliberate control rather than a limitation to be lifted later. The app runs entirely on Atlassian Forge, with compute and storage on Atlassian infrastructure, and the only network destination is the app’s own Atlassian-hosted endpoint; the share link, which carries the token, is handed to the subscriber out of band rather than over the app’s channel. On the publisher’s side the app only reads the shared page and on the subscriber’s side it only writes the replica. The only personal data it stores is a user identifier.&lt;/p&gt;

&lt;p&gt;Read more in our &lt;a href=&quot;/apps/page-sharing&quot;&gt;User guide&lt;/a&gt;.&lt;/p&gt;
</content>
  </entry>

  <entry>
    <title>Mermaid Diagrams 2.8: rebuilt on Atlassian Forge</title>
    <id>https://www.cloudscript.io/news/mermaid-2-8</id>
    <link href="https://www.cloudscript.io/news/mermaid-2-8"/>
    <published>2026-06-30T00:00:00+00:00</published>
    <updated>2026-06-30T00:00:00+00:00</updated>
    <category term="mermaid" label="CloudScript Mermaid Diagrams for Confluence"/>
    <summary>CloudScript Mermaid Diagrams for Confluence moves from Atlassian Connect to Forge, upgrades the rendering engine to Mermaid 11 and adds ELK layout, with existing diagrams carried across unchanged.</summary>
    <content type="html" xml:base="https://www.cloudscript.io/news/mermaid-2-8">&lt;p&gt;Version 2.8 of CloudScript Mermaid Diagrams for Confluence is now live on the &lt;a href=&quot;https://marketplace.atlassian.com/apps/1219878/cloudscript-mermaid-diagrams-for-confluence&quot;&gt;Atlassian Marketplace&lt;/a&gt;. The app first shipped in November 2018 on Atlassian Connect, and this release replaces that codebase with one built on Atlassian Forge, Atlassian’s own hosting platform for cloud apps. This change means that the diagram is now drawn in the reader’s browser from the source stored in the macro, and the app runs on Atlassian’s infrastructure rather than on a server we operate.&lt;/p&gt;

&lt;h2 id=&quot;mermaid-11&quot;&gt;Mermaid 11&lt;/h2&gt;

&lt;p&gt;The rendering engine moves from Mermaid 10 to Mermaid 11 (11.15.0 in this release), so any diagram type or syntax feature in the current Mermaid specification renders in the macro. In addition, the app supports the ELK layout engine for flowcharts and other node-based diagrams, selected through the diagram’s frontmatter (&lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;config: layout: elk&lt;/code&gt;), which produces tidier routing on larger diagrams than the default layout. The macro’s configuration panel keeps its three settings: the diagram source, a theme chosen from Default, Forest, Dark and Neutral, and a checkbox that prints the source beneath the rendered diagram.&lt;/p&gt;

&lt;h2 id=&quot;existing-diagrams-keep-working&quot;&gt;Existing diagrams keep working&lt;/h2&gt;

&lt;p&gt;Pages created with the Connect version continue to render. The new macro reads the diagram source stored by the older version, so nothing needs re-entering and no page needs editing. Diagrams are also included in Confluence’s Export to PDF as they appear on the page.&lt;/p&gt;

&lt;h2 id=&quot;export-to-word-and-export-to-email&quot;&gt;Export to Word and Export to Email&lt;/h2&gt;

&lt;p&gt;Both are temporarily unavailable while they are reworked for Forge. They are in progress and will return in a later release; until then a page exported to Word will not carry its diagrams, so keep the Connect-era expectation in mind if Word export is part of your workflow. Where an export is required, use Confluence’s Export to PDF.&lt;/p&gt;

&lt;h2 id=&quot;what-has-changed-for-administrators&quot;&gt;What has changed for administrators&lt;/h2&gt;

&lt;p&gt;Because the app now runs on Forge, Confluence administrators will be asked to approve the new version when it replaces the Connect app on their site. The app does not send your diagram source anywhere outside of Atlassian, since rendering happens in the browser. Your data is only stored in the macro on your Confluence page.&lt;/p&gt;

&lt;p&gt;Read more in our &lt;a href=&quot;/apps/mermaid&quot;&gt;User guide&lt;/a&gt;.&lt;/p&gt;
</content>
  </entry>

</feed>
