Provide the ability to disable loading of cutom rules

[oliverbrandt]

In a corporate environment with a centralised SQ service it is not desirable to allow changes to the rules from the client side by running an analysis.
Having the ability to disallow the usage of custom rules via SQ server side configuration would be a solution.

[Pablissimo]

This is an interesting one, I'd actually assumed that SonarQube was capable of preventing override of a setting at a global level. Shall take a shufty at the PR, thanks!

[Pablissimo]

So on the back of this - are you also limiting the specification of what tslint.json gets used? I'm going to start a conversation with the SonarQube gang themselves I think, as I'd have expected that you could lock down a setting from being overridden in a similar way that you can with web.config sections in the .NET world.

[oliverbrandt]

I'm not limiting what tslint.json gets used. This change was just to prevent uploading of new rules.

Due to corporate we should use the same rules / quality profiles for all projects unless e.g. some customer requires a different set due to their corporate requirements. As installing and running node from a maven build and using the TS plugin to run tslint does not work due to node not being on the path, I see no way to force the use of a specific tslint.json for the TS build running tslint.
I suppose changing the way tslint is invoked from th TS plugin and reviving the download of a tslint.json from the server might be a cleaner way. But as we want to get the "official" version of the TS plugin into production as soon as possible this implemention at least fixes a real blocker issue.

As I do not have any relevant experiences with .NET projects and SQ could you please elaborate on the lock down you mentioned?

[Pablissimo]

Sure - so in .NET when you're configuring an application (say, a web app) there's a hierarchy of configuration files not radically dissimilar to the way SonarQube presents settings. There's a machine-level configuration, an application-host level configuration, an application configuration and so on. Settings in lower-down files (nearer to the application) take precedence over higher-up ones, same as SonarQube. But for some settings there're security concerns - what level of sandboxing the application runs with, what proxy settings should be used for network connections etc.

In .NET-land, you can lock a section of a configuration file at certain levels, fixing the values at that level and causing an error when an attempt is made to redefine those settings lower down.

I had hoped that SQ would have something similar - an ability to say, for a given property 'I know what I want this setting to be, and I don't want anything lower down to be able to override it'. So maybe you'd set your custom rules at a global level as just blank, and lock it - preventing an individual project from changing the blank set to something else. Will report back if I hear anything, but suspect it's non-trivial changes.

As to your change, shall merge quite happily!