As the developers of Open Journal Systems, Open Conference Systems, Open Harvester Systems, and Open Monograph Press, the PKP team are experts in helping journal managers and conference organizers make the most of their online publishing projects. PKP Publishing Services offers support for:

As a customer of PKP Publishing Services, you will not only receive direct, personalized support from the PKP Development Team, but will be contributing to the ongoing development of the PKP applications. All funds raised by PKP Publishing Services go directly toward enhancing our free, open source software. For more information, please contact us.

1. Search the forum. You can do this from the Advanced Search Page or from our Google Custom Search, which will search the entire PKP site. If you are encountering an error, we especially recommend searching the forum for said error.

2. Check the FAQ to see if your question or error has already been resolved.

3. Post a question, but please, only after trying the above two solutions. If it's a workflow or usability question you should probably post to the OJS Editorial Support and Discussion subforum; if you have a development question, try the OJS Development subforum.

Your method sounds good to me -- if I recall, phpBb uses the same approach. It should be suitable for inclusion as a core feature unless unexpected complications arise in the implementation, which I don't expect OTOH.

I'd suggest making this a site-wide configuration option rather than a journal-specific one. In this case, you can add the configuration options either to the config.inc.php configuration file or the site settings page.

I did my best been carefully with OJS API and I think the patch follows OJS logic and coding standards but I'm unable to fix a couple of issues in the "OJS way":

a) How do I temporally store the password? to secure it a little I didn't send the pass in the activation mail (only user/token are sent) but when the new user request the activation, OJS needs to mail him/her password, so it need to be stored somewhere. May I store this within any accessKey? How?

b) Also related with the accessKeys... I think I really don't catch the concept. I understand I need to create a new key for each user (what I called "token") and I managed to store it successfully in access_key table but after this I'm unable to "validate" with the mail information.

That looks very close -- I suspect your access key validation problem is due to mismatching contexts (RegisterContext vs. ReviewerContext, when both should be RegisterContext). Otherwise the code looks fine.

Temporarily storing the passwords in an unencrypted manner is a tricky one; we've entirely avoided the problem so far and I'd suggest continuing to do so if possible. Plaintext password storage is a major security risk. You could consider including the username and password information in the first email, along with a note stating that they will not become active until the URL is followed...?

I suspect your access key validation problem is due to mismatching contexts (RegisterContext vs. ReviewerContext, when both should be RegisterContext).

Of course was this. Million thanks !!! How silly am I !! I'm the most stupid coder in this side of the sea...

Looks like I cut&paste from your "Reviewer" example and after reading it a hundred of times, this code was too much printed in my retina to notice the difference.

Temporarily storing the passwords in an unencrypted manner is a tricky one; we've entirely avoided the problem so far and I'd suggest continuing to do so if possible.

Your wishes are orders for me. It will be done as you suggest.

You could consider including the username and password information in the first email, along with a note stating that they will not become active until the URL is followed...?

Although I still believe the logical process is sending login information just when user is finally activated I full understand and agree in the security concerns you pointed, so the only choice I see is the one you recommend... but with a little variation (if it's also ok with you):

Instead of sending a single mail with activation code and login info, I suggest two separate mails that will be harder to sniff, hijack... whatever.

I hope I will finish the code tonight and create the patches that I will test tomorrow in our testing server but in a quite "real context" with clean OJS 2.1.1.0 code. After being sure patches work fine, I will forward to your team.

Thanks again (and again, and again) for your fast and invaluable help,

Patch validMail: With new code (for OJS2.1.1 with "diff -u") and translations to es_US and es_ES. As you notice in my posts, English is not my mother tongue, so probably a review will be required. Any way, is there any further translation required? A couple of bash scripts are also included, to facilitate the patch install (applypatch.sh) or recreate the patch (createPatch.sh -probably only useful for my development paths-) are also included.

Development notes: With comments to explain every add or change in the original code, as well as development decisions. I wrote those comments with "Zim" (a desktop wiki) and after exported to html, so document is readable, but is not perfect.