By default, OJS allows users to self-register as an Author, Reader, or Reviewer. You can turn off self-registration for any of these roles by finding the role in Users and Roles and clicking Edit, then unchecking “Allow user self-registration.” For more information see Learning OJS > Editing Roles.
You may also want to restrict self-registration altogether because your journal is only open to solicited submissions, because you’re a course-based journal (only allowing submissions from students registered in the class), or because your journal is discontinuing.
To close registration, go to Users & Roles > Site Access Options.
You can now select the radio button for “The Journal Manager will register all user accounts. Editors or Section Editors may register user accounts for reviewers.
Please see instructions in Learning OJS 3.
You can refer them to the instructions in Learning OJS 3 > Resetting Your Password for instructions on how to reset a password. If the user is having issues, please see instructions under Users and Roles > If a User Can’t Log In.
This is likely a problem with your browser’s privacy settings. Our software requires that cookies are enabled in your browser for you to log in. You can check the status of your browser cookies here. If you aren’t sure how to enable cookies, try selecting a lower security setting, or try a different browser. If you are still having problems, report them to the PKP Community Forum.
There are several ways to turn off notifications depending on the type of notification it is.
Users can modify their notification preferences through their personal profile in the notifications tab. After logging in, click your username on the top right corner followed by View Profile then Notifications. Users can then select their preference for public announcements, submissions, and discussions.
Another notification that editors may want to turn off is the new issue notification. When publishing an issue, an editor can select whether to send a notification to all users. Similarly, an option is presented to editors when posting a new Announcement.
If you opt-out of sending notifications when publishing an issue, but decide that you would like to send one after, see How do I send a message to my site’s users?
There are few scenarios where you might come across this message:
If you encounter this message as a result of the first 2 scenarios, please see the Users and Roles documentation for details on editing a user’s account to assign a different or additional role, and editing the role settings to allow access to different workflow stages. (based on the role’s access to workflow stages, or on which role you’re in when assigned to an article)
The third scenario is a result of the security measures within the recent releases of OJS to protect the review process. The system is recognizing the most recent role as a reviewer. A workaround for this would be for the editor to use the direct link to the editorial workflow, i.e. you add /workflow/index/MSID/3 right after index.php in the URL: https://YourJournalURL/index.php/acronym/workflow/index/XXXX/3, where xxxx is the MS ID #.
As a Journal, Press, or Conference Manager, you can “remove” and “disable” a user’s account. Removing a user will only remove them as a user registered with your journal, and will not delete them from the site. Disabling an account doesn’t delete it – it just makes it so that a user can’t log in with that account. In both cases, the user cannot register again using the same email address.
User deletion in OJS can only be done by using the Merge Users feature: you pick the user to be removed and merge their account into another one. We don’t provide a one-click delete feature because users typically have a lot of information and actions attached to their account that must not be orphaned: submitted files, completed reviews, editorial decisions and so on. We essentially mandate that all of these items must be passed on to another user before the user can be removed from the system.
Instructions on how to merge users is available in the Learning OJS user guide under Users and Roles > Merge User.
The command-line tool to merge users is tools/mergeUsers.php.
In a single installation, only the Journal Manager or Journal Editor will have the ability to edit a user.
In a multi-journal installation, Journal Managers or Journal Editors will only be able to edit user accounts that were originally made on their journal and not one created in other journals.
The easiest way to send a notification to all registered users is to create an “Announcement.” In addition to sending a message to all users (who have not opted out of email notifications), an Announcement is also displayed on the journal homepage and saved as an archive. See Website Settings > Announcements in Learning OJS 3 for details.
If you would like to send a message to all users in a particular role you can use the Notify feature. See Bulk Email Notifications by Role for details.
For more refined communication with users and marketing communication, we recommend an external tool, such as Mailchimp. You can export your users in a CSV file under Tools > Import/Export and import them into the external tool.
If you want to communicate with a group of users who are all assigned to a particular submission, you can use the Discussion feature on the submission.
Announcements are recommended when you want to post a notice to the journal website and / or send a broadcast email to all users registered with the journal.
The Notify feature in OJS 3.3 needs to be enabled for the journal by the site administrator. When this option is enabled, emails can be sent to all users in one or more role, such as all journal managers and / or all section editors, etc. See Site Administration > Bulk Emails for instructions on enabling this feature. This option is recommended for sending practical, core service emails to users who are actively working on the journal. For example, you might send an email to all copy editors reminding them of the “house style” for a particular word use or spelling.
Once the Notify feature is enabled, you can send messages under Users and Roles > Notify. Note that misuse of this figure to send unsolicited email may violate anti-spam laws in some jurisdictions and may result in your server’s emails being blocked as spam. Seek technical advice before enabling this feature and consider consulting with journal managers to ensure it is used appropriately.
If you discover a large number of spam user accounts in your journal or press (for example, the fake accounts might have a name like “12 alekssafer alekssafer alekssafer”), you can remove the accounts and take steps to prevent additional spam accounts.
The first step in solving this problem is to have your system administrator enable ReCAPTCHA for your journal registration process. This should block or at least limit any further fake account creation.
Once that is done, you can then begin to clear out the accounts. If you have access to the OJS server, you or your system administrator can remove multiple users at a time with the “merge users” tool. However, if you are limited using your Journal Manager account you can do it using the Merge Users feature (See Learning OJS: Users and Roles > Merge User). You would mark the checkbox for one or more of the fake accounts, and then merge those accounts into another fake account, or into a temporary account, you create for this purpose. Once the fake accounts are merged, they are removed from OJS.
The Site Administrator is created when first installing OJS, and typically there is only one Site Admin for any given installation. In order to grant another Site Administrator, you’ll need access to your database (e.g. through a tool like phpMyAdmin). This is usually part of a CPanel login on a typical server. You’ll need to create a user account and then use the SQL to promote them to Site Admin.
Check what the user group ID of your administrators group is by running:
SELECT user_group_id FROM user_groups WHERE context_id=0 AND role_id=1;
It’ll probably give you a 1 back as a result. Then, you can grant that to your user:
INSERT INTO user_user_groups (user_id, user_group_id) VALUES (<new_admin_user_id>, 1);
…where <new_admin_user_id> is your user ID, and 1 is the user_group_id you got from the first query (probably a 1).
If your site Administrator is no longer available, you may need to find their login credentials and designate a new site Administrator. This is difficult because Journal Managers and Editors cannot log in as an Administrator or edit an Administrator user account.
To reset an Administrator’s password, follow these steps:
SELECT user_id FROM users WHERE email = 'pkp-support@sfu.ca';SELECT user_id FROM users WHERE username = 'admin';[security] section of the config.inc.php configuration file. This will be sha1 or md5.UPDATE users SET password=MD5(CONCAT(username, 'newPasswordHere')) WHERE user_id = 15;Alternatively, you can update the email address for the administrator account in your database to an email account that you have access to, as long as it is not already associated with an existing user account. You can then follow the standard password reset steps in the OJS/OMP/OPS interface.