A website developer role, with fewer permissions than admins but more/different than journal managers

Hi everyone,

Currently, my involvement with OJS is in the (re)design of journal websites and improvement of their non-article content (e.g. introduction, focus and scope, history). In this capacity, I work with some OJS installations that cover a single journal, and other behemoths that feature almost a hundred journals (such as Universitas Gadjah Mada’s journal platform). One of the common issues I encounter is that, unless I am an admin, I can’t install themes or edit the template files. And conversely, because I’m given journal manager-level permissions, I’m given potential control over the editorial workflow of a journal.

Of course, there are very good (security) reasons for why only admins can install plugins, but I think this is an interesting problem of simultaneously too few and too many permissions—or rather, wrong permissions.

In my experience (in Indonesia), journal managers and editors-in-chief have no interest, let alone knowledge, in carrying out the actual tasks of updating their journal website’s stylesheet, modifying the favicon, editing the header and footer, and so on. These tasks are delegated to assistants, who are almost always young interns unfamiliar with OJS. With journal manager accounts, they have the power to change anything, and at least once, I have been tasked with helping a journal recover its introduction and editorial information after such an intern accidentally deleted it all. (This is that quirk of OJS 2 when a person will cancel a page reload before it’s finished and then save it, without realising none of the content had loaded yet.) So, not only is the journal manager role afforded power it might not need, it also introduces the potential for user error.

Perhaps there is a middle-ground here, where a person has permissions to install and modify themes (including the css), and potentially to edit specific website content, but have no access to any other part of the journal (specifically the editorial sections)?

I understand that my use case is limited to probably only me, but nevertheless, I thought I’d just share this idea. :slight_smile:

1 Like

Hi @jaybaeta,

Hmm, interesting question, and I’m open to suggestions, but let me quickly describe our current thinking. We currently strictly require Site Administrator privileges for anything that…

  • Modifies a locale file (e.g. the Translator plugin)
  • Introduces outside code to the installation (e.g. installing a plugin or theme)
  • Transforms something potentially sensitive outside the scope of the current journal (e.g. merging user accounts, or administering a user account that’s active in another journal)

Particularly the case of a plugin would be hard to relax, since any plugin (including themes) has the opportunity to execute arbitrary PHP on the server side. Presumably a malicious plugin could monkey with permissions, download files, or even delete the whole installation. PHP doesn’t have good sandboxing tools (yet), so that’s a consideration we’re going to have to consider for the foreseeable future, unfortunately.

One option we’re hearing more interest in is multiple deployment using Docker. Rather than hosting several installs in the same OJS, it would mean deploying more OJS installs using container tools. This permits a lot more freedom for journals to work with plugins and modifications but without impacting others. I understand it probably won’t be available as easily as a commodity PHP account but I suspect it’s becoming a lot more popular.

Alec Smecher
Public Knowledge Project Team