OVERVIEW
HighQ 5.3 was announced at Legalweek New York 2020. If you haven't seen the announcement, please read the press release and visit our What's New web page. You can also watch the HighQ 5.3 on-demand webinar to learn more about the top features.
This sandbox instance - https://integrationbeta.highq.com - has been upgraded to HighQ 5.3. Please check your API integration to confirm that it continues to work with 5.3. The API Swagger documentation has been updated accordingly and can be found at the following location https://integrationbeta.highq.com/integrationbeta/showSwaggerUI.action. Please note that we do not plan to update the documentation in the developer community but will only be updating the Swagger documentation from now on.
The API is backwards compatible so your integrations should continue to work without any change. Please comment on this blog post or raise a support ticket if your integration has any issues with HighQ 5.3.
Key API's added or updated in HighQ 5.3
Site templating API's
The following API's to manage site templating has been added
- Creating a site from a template
- Saving a site as a template
- Exporting a template
- Importing a template
- Getting, Adding, Updating and Deleting templates
Site security API's
API's to provide site security details if they are enabled for the site
- 2FA enabled site
- Password-protected site
- Site with Terms and Conditions enabled
HighQ 5.3 changes for the files module
I agree Andrew Quinn - there shouldn't be any modification of contents on save. I think the issue we face is we have none 'developer' people working on these pages and it would require a large investment to get them working in a process of using git and us doing releases for every wiki page when they need to make a change of a title on a google chart for example - also we've started doing work for clients on their instance which they'd like to own so making it external could be tricky when they'd like to amend going forward.
But yeah ideally everything should be referenced from an external file - also allows for use of 'better' javascript which doesn't break the highq html validation.
On a further note, my opinion is that they should not be modifying the contents at all - they could not possibly account for all use-cases and styles. In this particular instance, it's not just (single line) comments that can cause issues, many code authors in the javascript world DO NOT USE SEMI-COLONS, instead use line breaks to separate statements. I don't personal subscribe to this but there are plenty out there that do, and guess what, minify to one line and you have a problem.
I would encourage, where possible, to implement javascript used in dashboards, or wiki pages, as external JS files you include in via
We almost always use this approach, and it was our clients using our older sites (with legacy inline Javascript) that alerted us to non-working pages, that we were even aware of this change to Collaborate regarding the modification of the content.
Including it as an external script file (say on your S3:// CDN) does come with an important caveat:
------> MAKE SURE THERE IS NOTHING SENSITIVE IN THESE SCRIPT FILES ------
Andrew
Hi Ryan McDonough, I have already raised a support ticket about this: Ticket #79498: 5.2.11 - Collaborate modifies Wiki pages that contain Javascript causing issues.
It seems HighQ have fixed this in the latest patch for Collaborate 5.3 (5.3.3). We have yet to receive the patch so I cannot confirm this has been fixed. You may want to raise your own support ticket, if you haven't already, citing the ticket number above and requesting for the latest patch version (5.3.3) to be applied to your instance.
Andrew
We've noticed that HighQ 5.3 is minifying JS onto one line on wiki pages - great idea in concept, however if you have a comment in the code to provide explanation about what it does, then suddenly anything after that comment is now a comment and breaks all the JS. The minifier really ought to remove comments if it's going to do this
Just throwing it out there, I'm very concerned about this line: "Please note that we do not plan to update the documentation in the developer community but will only be updating the Swagger documentation from now on."
We're concerned me on multiple levels:
1. Swagger doesn't allow users to comment on the documentation, which is often a very helpful component of the community.
2. This would seem to leave behind a "zombie" set of documentation here in the developer community that will potentially lead people in the wrong direction.
3. (Selfishly) for Power Users like myself who dabble in the API (under guidance from our developers) it now creates an extra barrier to entry.
Comments
5 Comments