While using Billable Time I want to be able making use of formatting (bold, underlined, italic, tabs, new line, etc.).
Simple example; I write this line as Billable Time:
“Remote Support: Troubleshooting (Name of Engineer); Case: User X called me with issue Y. Result: I did this to fix that and solved.“
However it would be great to have some formatting options as well as making use of new lines.
Let’s say I want it to be formatted as follow:
“Remote Support: Troubleshooting (Name of Engineer) Case: User X called me with issue Y. Result: I did this to fix that and solved.“
To get this working, I need to enter HTML tags (this editor doens’t allow it, so making use of a quote to illustrate):
“Remote Support: <b’>Troubleshooting</b’> (<i’>Name of Engineer</i’>)<br’><b’>Case:</b’> User X called me with issue Y.<br’><b’>Result:</b’> I did this to fix that and solved.“
>>> This is a very cumbersome method and out of date.
ideas Wouldn’t this be a great feature? So we can enrich our work to our customers and provide overview and easyness for us users who are writing it .
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.
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.
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.
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.
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.
Themes are large development and are available for all viewable documents and creating a whole theme for a tiny modification would be an overkill:
The theme list would be quite large since for every footer text combination, there is going to be a separate theme
The dropdown would be even larger since you will see Quote, Payment, Invoice themes in a single list. This also is error prone.
Maintaining a unified theme with a lot of variants isn’t efficient, let alone maintaining compatibility with updates
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
Footers can store atomic data with little to no scripting. This will make the life of whoever is maintaining them easy.
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?
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.
Default theme no longer supports HTML in fields for security reasons. You can use custom theme which can restore this function if you understand the risks.
Just an FYI. I also had a couple of HTML statements in the business details. The raw theme fixed most things, but my business details still showed the tags on the printed documents instead of bolding the output. I had to remove the tags for now.
These changes are chaos for us, confusing our users and delivering horrible documents to customers.
I understand the security and layout conistency thought but it was these nice little easy to use (for non-technical users) like a couple of HTML tags to bold a line or show a link on a view screen that really made manager customizable in a very easy user friendly manner. We seem to be having to become more and more technical or deal with more and more complexity in set-up to make these little features work again and have to scramble to deal with changes/loss of functionality on more and more updates.
Please restore HTML in the view forms without having to attach/configure (not that is available yet) a specific custom theme for each screen. It’s problematic.
Right now - Documents: Fine, I can and have turned on the HTML theme, but now I have to apply that theme per document.
View forms - Total mess. No way (as of right now) to turn back on. I really don’t want to have to apply a custom theme view form by view form here. The maintenance complexity is getting silly. How about just a setting somewhere that simply allows a toggle of HTML in view forms on/off and applies across all view forms within the application. This would allow users (administrator users) to allow html if they understand risks without a crazy amount of view form by view form configuration maintenance.?
@lubos, as some (safe) tags are sometimes used all over the Business (<b.>, <u.>, <i.>, <br.>) from all Inventory Items to all Custom Fields, to descriptions, etc, for now I installed the Raw HTML Theme.
However, with or without it installed, since a couple of updates, the description of all Custom Fields is rendered aside the title, not stacked under.
Is that also been changed?
.
