UsageStats plugin not visible for journal managers

[ajnyga]

Hi,

I know that the UsageStats recently changed so that it is handled from the site level. However, I understood that journals can still bypass the site level settings by making their own journal level settings. For example, they can enable the public download stats.

But, I recently learned that the journal managers can not see the UsageStats plugin at all in the plugins listing? Is this intended?

OJS 3.1.1.2

[ajnyga]

Adding return !Application::getRequest()->getContext();
here https://github.com/pkp/usageStats/blob/master/UsageStatsPlugin.inc.php#L176
is probably enough.

However, it then gets a bit complicated. The plugin does appear now for JMs, but it is marked as disabled inside a context so journals will probably think that stats are not being collected for their journal.

If I enable it inside a context, usagestatsplugin enabled appears to the database for that plugin with the context id as expected.

But I think that the a plugin that can be enabled from site level should work so that if you enable a plugin on the site level, the plugin will appear as enabled inside a context and a JM can not disable it?

[bozana]

Hi @ajnyga and @asmecher, it is intended that the UsageStats plugin is a site-level plugin i.e. manageable only by admin user. And I believe all site-level plugins are treated the same in the JM view, correct? Thus, is this a general question/feature to be considered for site-level plugins?

[ajnyga]

Welcome back 😄

[ajnyga]

I think that it would make sense that

1. Site-level plugins can not be disabled by journal managers BUT
2. Journal managers can change the context specific settings of such plugins.

I mean at the moment journal managers can not for example enable the article level metrics display by themselves.

Maybe there should even be a distinction between settings accessible for site administrators and settings accessible for journal managers?

[bozana]

Welcome back smile

I am very slowly coming back... :-)

[bozana]

I think that it would make sense that

1. Site-level plugins can not be disabled by journal managers BUT

2. Journal managers can change the context specific settings of such plugins.

I mean at the moment journal managers can not for example enable the article level metrics display by themselves.

Maybe there should even be a distinction between settings accessible for site administrators and settings accessible for journal managers?

@ctgraham started a discussion and work on a general solution for this, s. #1923. I do not know what is the current status there, but... would that consider the feature mentioned here? -- So we can maybe continue the discussion there?

[ajnyga]

Let's see what Clinton says.

Just a note that the code addition I suggested above is from here: https://github.com/asmecher/customHeader/blob/master/CustomHeaderPlugin.inc.php#L130-L140
I thought it was a mistake that this line was missing from the usageStats plugin.

[ctgraham]

Clinton just got pinged with this two years later. The Usage Stats plugin is a particularly interesting use case in that it has (IMO) both system level and context level settings:

• System settings:
  • Log file specifications
  • Data privacy options
  • Optional statistic information
• Context options
  • Statistics display option

The real solution here, I think, is to move the context options out of the plugin settings form and into the Website settings.

[ajnyga]

The real solution here, I think, is to move the context options out of the plugin settings form and into the Website settings.

Agree, even though this is a plugin, the settings for it should be more accessible. And also agree, that not all settings here need to be context specific.

(ps. I was ready to wait another year and the re-ping you)

[NateWr]

I think we're well on our way to addressing this with Bozana's stats work for 3.4. The usage stats plugin is going away entirely and it's being integrated into core. If there is anything remaining after that work is completed, please file a new issue.