Enable/Disable features on a per 'user' or per 'website' basis?

simon_hayden · January 11, 2021, 4:04pm

In an On-Premise Matomo instance, is it possible to enable or disable the Premium Features such as Custom Reports, Heatmaps, Session Recordings, Media Analytics on per ‘user’ or per ‘website’ basis?

I run analyitcs for multiple customers in a single Matomo instance. I would like to offer my customers to opt-in to additional features offered by the Premium Feature add-ons above, and then enable/disable them for that customer’s user(s) or website?

I can’t see these options in the Matomo web app UI (although I haven’t purchased the Premium Feature Add-ons yet). Can this be done in the Web UI or in the PHP config files? If not, I suppose the next best thing would be custom theme(s) where I simply hide the relevant features using CSS and JS?

Many thanks for your comments, opinions and suggestions with this.

Jason_1282 · January 14, 2021, 12:57am

Hi there,

Currently it is not possible to restrict users to particular features in the UI. The only restrictions available are what site the user has access to. https://developer.matomo.org/guides/permissions

Thanks

JThiel · July 7, 2022, 12:03pm

Hi @Jason_1282,

we just ended here with the exact same question and the same usecase ;-). And still couldn’t find anything regarding this in the docs or config files. There are just ways to force-activate plugins in the config file. But nothing to disable some.

Is your answer from last year still valid? You only answered parts of Simons original question so I would like to re-ask the part of “is there any (suggested) way to solve this”? Like filter / hooks or such?

I believe a Multi-Tenant setup might solve this? But how would the licensing work for your premium plugins?

Thanks,

Jan

karthik · July 8, 2022, 12:19am

Hi @JThiel ,

The user level in the license relates to the number of registered users in your Matomo (all users are counted regardless of privileges). It’s not possible to restrict the number of registered users who can use the plugin to match the license. As Jason mentioned the only access control currently available is which site a user can access https://matomo.org/guide/manage-matomo/users/

JThiel · July 8, 2022, 7:20am

Hi @karthik,

my question was in particular not about the user based licensing of the Premium addons.

The yet unanswered part of the question was simply how to limit certain plugins to specific websites configured in Matomo. This was also part of the original question which was sadly unanswered.

Just consider usecases like the “ecommerce” option. This is something you can configure per site. Which totally makes sense as some website have other requirements than others. This is true for some plugins as well. As they do deliver functionality which might or might not be useful or even wanted for certain websites.
To speed up those websites in Matomo and make the UI cleaner it might be feasible to allow (functional) plugins to be limited to certain sites only. So those plugins are not loaded into the Matomo Dashboard at all.

The config file allows site based activation of plugins by adding a config block with the ID suffix. I haven’t tried that out to be honest… So the opposite could be possible as well.

heurteph-ei · July 8, 2022, 8:53am

For ecommerce, I think that if you configure the site as ecommerce site (in the Measurables configuration), then the menu will be available, and if it is not configured as ecommerce site, then it won’t be available.
Probably the same for some widgets (which ones? I don’t know) vs the fact the site has been configured as Intranet or Internet.
I think your need is an important feature. The you can create a neature request in the Matomo GitHub repo:

JThiel · July 8, 2022, 1:19pm

@heurteph-ei Thanks for your feedback.

With >2k open issues on Github I was not convinced that posting there would do any good. But hey, let’s give it a try

github.com/matomo-org/matomo

Allow Plugins to be enabled/disabled on a website level in addition to the default global scope

opened 01:17PM - 08 Jul 22 UTC

JanThiel

Enhancement

Plugins are currently globally activated and thus apply to each website in a sin…gle Matomo installation. There are features delivered via Plugins which might not be required or wanted on a single website. This is kind of the case with the built-in "ecommerce" features which can be enabled on a per site base. ## Summary I propose to add the ability to add Plugins on a per site base in addition to the current only existing default of a "global" activation. This would allow Matomo Admins to optimize larger installations by limiting additional features only to those websites which actually require them. In theory this should allow peformance boosts in the processing as well as the UI. As less features should result in better processing and loading times. I would suggest to allow Plugin devs to determine whether their plugin supports a "global", a "single website" or "both" modes. Whereas a globally activated plugin cannot be disabled for a single website. There are concepts like these in major systems like WordPress. Which allows a much more granular control of the code being executed in the context of a single website. As I do see strong parallels of a WordPress Multisite setup to the way Matomo works for several websites, it would be a beneficial addition to add this level of control. This would also raise the awareness of developers that there is a differentiation required between global settings and per site settings. We just came across such an issue with one of the official Matomo Premium plugins where this was kind of "overlooked" and site specific configs were setup and stored globally. Thus leading to data being globally accessible by admins of a single site who should not have access to the information of other sites.

karthik · July 11, 2022, 9:31pm

Hi @JThiel ,

An new internal ticket is created for your request.

Totally understand that perspective and I’m sorry we don’t have a better option for your use case currently. Of course nothing is written in stone, and if our product team sees other requests like yours to make changes, that may change. I can’t make any promises what the future holds, so I want to be honest about our current plans here.