HTML inside fields stopped working on default View screens

1

As an example, this used to show an embedded Google Calendar but now it shows the html code.

image
image898Ă—811 64.1 KB

Moreover, the html tags inside business details fields are not rendered anymore.

2

There is new default HTML theme which does not allow custom HTML being injected through data. This is to resolve issue so that default HTML theme will always work regardless of input.

Now, there is a solution. Just like you can already provide your own HTML theme for transaction-type documents, it will be soon possible to provide your own HTML theme for any View screen (including reports etc.)

So if you want to relax the rules and allow HTML in your themes, then you can provide your own HTML theme. AI can help you to make it more “relaxed” however you need to be aware of security risks too. If you provide multi-user access, theoretically restricted user could inject into View their malicious script which you can then run without knowing just by merely viewing. At this point this is just theoretical risk, I’m not aware of anyone ever exploiting this but it would be only a matter of time.

Anyway, the bottom line. It’s not that this won’t be possible. There will be just extra step to achieve that. Defaults need to be secure.

I’m actively working on custom themes so they can be applied to anything viewable in Manager.

3

That makes sense.

However, I still think that this total blocking of html is a bit too much. I would assume that pure HTML does not pose any real security concern – other than maybe an offensive layout, but I could wrong.

However, since this block is implemented on the Theme layer, I suppose I can keep the script and style blocked but spare all other tags.

However, I wouldn’t be able to do that for folders just yet.

I personally liked a suggestion by a forum member to reimagine Footers as html blocks. I assume there it would be possible to allow more control of html content without having to mess with the default theme code.

4

True but when layout breaks unexpectedly, it’s not obvious why it broke. People get stuck and don’t know what to do thinking it’s fault with the program rather than their input.

So I see default theme always working as an escape hatch confirming it’s not the program but your input.

But if footers contain script which are modifying default theme, then any change to default theme will break footers. So it’s not future-proof.

Footers were introduced so that people could have additional content shown on their documents instead of diving into custom themes. But now with AI, I’m reconsidering it because it turns out AI is pretty good at crafting custom themes.

The latest HTML theme which I didn’t roll out to all documents yet is using just pure HTML/JS/CSS. It’s very straightforward with nothing odd. No use of postMessage api etc.

For example, previously if you wanted to craft custom theme using AI, some context needed to be provided for AI to understand what it’s working with. New HTML theme is so simple, AI can figure out what it’s looking at without any additional context.

And if custom themes will be so easy to customize using AI to your liking, then there won’t be really any purpose for footers anymore.

5

I still think Footers is a good addition because not only does it allow users to add static and dynamic content, but it also allows users to pick and choose which footers to show in each individual document.

For example, which set of terms and conditions to show on each specific Quote. That’s not something that Themes are meant to do.

So I recommend that Footers be kept because of their simplicity, ease of use, and versatility.

Anyway, I think I will remove this from bugs now.

6

Sorry to step in here but you can also select the necessary theme for this. So rather than having the footer selection you would just select the theme that has the required footer information.

7

Themes are large development and are available for all viewable documents and creating a whole theme for a tiny modification would be an overkill:

  1. The theme list would be quite large since for every footer text combination, there is going to be a separate theme

  2. The dropdown would be even larger since you will see Quote, Payment, Invoice themes in a single list. This also is error prone.

  3. Maintaining a unified theme with a lot of variants isn’t efficient, let alone maintaining compatibility with updates

  4. Footers are small chunks of info, kept separate for each type of document with the ability to combine them. 4 separate footers could allow the user to create unlimited combinations – instead of unlimited dropdown options :fearful:

  5. Footers can store atomic data with little to no scripting. This will make the life of whoever is maintaining them easy.

8

Currently our documents look real bad with the HTML code exposed.
I am wondering if this is connected to the old Classic Custom Field which are littered in our Manager.
What is the actual fix for this please?

  1. A coming update to Manager
  2. Untick the "Show Custom field tick box
  3. Remove the affected custom fields
  4. Delete the fields HTML content

How are people handling this change please?

9

Would it be possible to allow HTML in inputs but sanitise it to formatting elements only so it’s still possible to use tags like <b> without having to make a custom theme? Or alternatively, Markdown formatting.

10

That wouldn’t be a bad idea. In fact, that would only add to the user-freindly user experience of Manager