Last month, we discussed logging user submissions to the SEC in our blog post LDC 154. Well, thinking more about this, I realized it was probably not a good idea to not secure the log file. If someone makes a mistake, and files a document they shouldn’t, they could simply alter the log to show different times or users filing the document, and there is no record of it. A malicious user could easily just change what the log says! This is unacceptable and easily within our power to fix. To do so, we’re going to use a common function, the MD5 hash function.

I had an interesting issue crop up this week: a client had a file that had a 21 inch indent on a paragraph, causing problems when the file was printed to PDF. When GoFiler converts your Word file to HTML, if there are a lot of spaces or tabs on a line, it can cause GoFiler to interpret it as having a large indent level. Normally this isn’t a big deal, but if the indent ends up as large as this, it can cause rendering issues. So, I was asked if there was a way we could test for this, and figured it would be an interesting problem for a blog post.

This week, we’re going to revisit a blog post from early 2018, Validating with the XBRL Object. This was a relatively straightforward script. It hooks itself into the validate function and adds an additional layer of validation for XBRL files. Having seen a couple of issues with blank element names in XBRL causing problems this past week, I figured it would help to create a script that enhances our default validation to detect these blank names and add in a temporary placeholder name so that it can be removed.

When you file something to the SEC, there are a lot of data points that can be tracked from that event such as: if the filing was live, when the filing process began, when GoFiler began transmitting the file, and when GoFiler finished transmitting the file. This information can be gleaned different sources, including the log file and the project file metadata. However, there is no one place where filers can obtain this information. With Legato, we can set up a small script that triggers when we file a project, and simply records information about that project into a log file in the same folder as our project.

In previous blog posts, we have shown a lot of examples of tasks you can use Legato to automate. We’ve gone into detail on how these scripts work, what UI functionality is required to support them, and ways they can be improved and added upon to increase the functionality. Way back in LDC #67, we even discussed best practices that can be applied when writing applications. One topic we haven’t really covered though, is how to estimate the complexity of a task, and if it’s even a suitable task for Legato to tackle. Keep in mind we can really do anything with Legato... but there are definitely times where we should just step back, and say that a task is outside the scope of what a script should handle.