archimatetool / archi

Archi: ArchiMate Modelling Tool
https://www.archimatetool.com
MIT License
914 stars 267 forks source link

Feature request: ASPX for HTML Reports #969

Closed AlbertoDMendoza closed 7 months ago

AlbertoDMendoza commented 9 months ago

Following up on topic 1429, it would be great to export the HTML report but with ASPX extension instead.

This is a workaround due to limitations imposed by SharePoint Online on JavaScript to 1) not allow custom scripts 2) if enabled, only allow custom scripts to certain file extensions. This workaround is to address point 2.

Background: SharePoint makes a differentiation between site scripts (json based actions) and custom scripts. JavaScript falls under custom scripts, and custom scripts can only be executed by custom pages. Per Microsoft's security recommendation, the default is to not allow custom scripting in SharePoint sites as (rightfully so) a rogue script have security implications, so there's a level of risk and security a site admin must be willing to accept by enabling this. For more background read this and this, and this.

For those willing to accept the risks: 1) Enable custom scripts by enabling custom pages, follow this: https://learn.microsoft.com/en-us/sharepoint/allow-or-prevent-custom-script#to-allow-custom-script-on-other-sharepoint-sites

2) Once custom scripts are enabled, only certain file extensions are allowed to execute them, ASPX being one of them. See:
this

This request is to have an option on Archi to use .ASPX instead of .HTML within files and references in the HTML Report for it to work with Sharepoint.

Phillipus commented 9 months ago

This request is to have an option on Archi to use .ASPX instead of .HTML within files and references in the HTML Report for it to work with Sharepoint.

That's not as simple to implement as it may appear. The HTML report uses StringTemplate files like this one. You can see that there are hard-coded .html extensions there. So we'd need an additional set of templates with internal .aspx extensions as well. Also, the hints files have .html extensions. And there are other internal things that would need changing which are not straightforward.

TBH, it would be simpler to run a post-processing script (could be done in jArchi) to rename the file extensions and then open each file to replace the extensions in links. But one would have to be careful to not rename extensions that might be part of a some text in a documentation field for example.

AlbertoDMendoza commented 9 months ago

I was afraid something like this would get in the way. Honestly the single page jArchi script is a better solution, but it's missing features like deeplinks and alasql, I though this would be an easier workaround to implement natively than to add extra features to the script. Thanks for the quick reply.

DavidLowBHA commented 7 months ago

Just adding a vote for this functionality as it would assist in sharing this information internally with our Organisation.

I have got it to run in a SharePoint embed webpart using an extension rename and then doing an internal file rename of html to aspx and does work ok. Main issue is I lose the zoom controls that can come in handy when looking at larger views.

Phillipus commented 7 months ago

Just adding a vote for this functionality as it would assist in sharing this information internally with our Organisation.

I have got it to run in a SharePoint embed webpart using an extension rename and then doing an internal file rename of html to aspx and does work ok. Main issue is I lose the zoom controls that can come in handy when looking at larger views.

We've already said in the comment above that you can post-process the report by renaming the files and links to .aspx. If parts of the report are not working after that the reason is clear - the usage is not supported.