Active development of JAMWiki has ceased, and bug fixes and support will be limited at best. If you are interested in taking over management of JAMWiki please send an email to the jamwiki-devel mailing list.


ktip.png This page (and all pages in the Tech: namespace) is a developer discussion about a feature that is either proposed for inclusion in JAMWiki or one that has already been implemented. This page is NOT documentation of JAMWiki functionality - for a list of documentation, see Category:JAMWiki.
Status of this feature: NOT IMPLEMENTED. This feature has been on the Roadmap for some time but has not yet had any code written for it. Note that there is some legacy (unused) code still in the codebase from the original JAMWiki 0.0.1 release that may or may not be a good starting point.


There are a few points on the roadmap concerning email support.

  • Send user an email after registration to activate his account. Roadmap#Email_Support
  • Send user an email when he has forgotten his password. He gets a link, where he can enter new password. ForgottenPassword
  • Email notification when topic is updated.

Instead of notifications about changes, users should use RSS feeds.

The email component needs this information, if no local mta is available:

  • Address of SMTP server
  • Port of SMTP server
  • Account on server
  • Password for account
  • Reply address

Configuration should be done during setup process and optional on an administrator page.

Existing code:

org.jamwiki.WikiMail.sendMail(String from, String to, String subject, String body)



  • Send email and creates validation codes. √
   String sendActivationLink(...); // called from RegisterServlet
   String userForgotPassword(...); //called from LoginServlet


Called by links in emails.

  • add page with textfield to enter validation code //Not implemented yet
  • accepts calls to activate user √
  • accepts calls to reset password √
  • 3 Parameters 'action' and 'code' and 'user'. Action can be 'registration' or 'reset'. 'code' contains validation code and user the username.


  • Checks if email support is activated and sends email. √
  • Shows page with information to check email. √


  • Add Button in LoginServlet beside password field to request password reset. √


  • add interface, which should be informed about all topic changes.
      void topicChanged(Topic topic);
  • Not implemented yet


  • add configuration for email server √


  • Add columns "enabled" and "validationCode" to WIKI_USER. √
  • Update of create/select/update/insert statements √


After Registration activation link.jpg New login page login-reset.jpg Request new password reset-pasword-dialog.jpg After request reset-link.jpg After following link fo entering new password new-password-details.jpg Confirmation that password has changed after-reset.jpg


A couple of quick comments:

  • First, it's awesome that someone is looking into email capabilities as that's one of the more highly requested features, but I've not done any investigation, mostly due to being too lazy to install a mail server.
  • Second, it would probably be better if all mail settings were configured only from Special:Admin and not from Special:Setup - I'd like to limit setup to the bare minimum necessary to get a system up and running. Additionally, quick & easy setup is one of JAMWiki's selling points :)
  • Finally, it would be cool if this was implemented in a generic enough way that we could easily allow email notifications when topics are updated. The company I'm working at now has requested that since people use email much more than they do RSS readers. That feature doesn't need to be made available immediately, but it would be good if it was easy to implement later.

Thanks again for getting this started! -- Ryan 23-Jul-2007 08:51 PDT

What's the difference between WikiUser and WikiUserInfo? They contain almost the same information. Mike 25-Jul-2007 11:17 PDT

The original idea was the WikiUser and WikiUserInfo would provide a way to allow external systems like LDAP to be used since the WikiUserInfo object would contain fields that weren't JAMWiki-specific and might be stored elsewhere. As the authentication & authorization system has evolved I'm not sure if that distinction has been maintained. The major to-do item for 0.6.0 is a re-work of the authorization rules, and auditing to cleanup anything that's no longer correct might make sense as well. -- Ryan 25-Jul-2007 11:28 PDT

Where should email settings be on AdminServlet? After Parser settings? Mike 25-Jul-2007 16:34 PDT

I'm not great with UI - obviously - so I'll defer to your opinion and those of others who have better aesthetic sense than my own. That said, putting it after parser settings makes sense since the "general" and "parser" settings are more likely to be updated than email settings, while database and LDAP settings probably won't need to be modified at all once a wiki is set up. -- Ryan 25-Jul-2007 16:42 PDT

Is there a way to get an absolute link to the wiki or a servlet eg. or Mike 26-Jul-2007 05:46 PDT

I know I can get the current servlet url from the ServletRequest object. But is it possible from outside an servlet? Mike 26-Jul-2007 08:19 PDT
Can you provide an example of where you would want to use this functionality? I believe Spring may offer some utility methods for pulling site information, but most of the time I think you should have a ServletRequest available. -- Ryan 26-Jul-2007 08:56 PDT


After my holidays I have committed some code to my branch mikegremi. There is are configuration setting for email on the Admin page and sending email with activation link and forgotten password are supported. To test just check out my branch, go to /jamwiki and run 'mvn jetty:run'. I would like to merge in to trunk after the next release. Mike 20-Aug-2007 23:31 PDT

I haven't had a chance to look through everything you've done in detail, but what I've seen definitely looks reasonable. It looks like the 0.6.0 may get pushed back another week or so due to some newly reported bugs, but hopefully thereafter work can start on 0.6.1 (or possibly 0.7.0, depending on the number of changes). Hopefully that won't be too long to wait! -- Ryan 20-Aug-2007 23:57 PDT

June 2008 Update

This code has not yet been merged to trunk, but there is significant interest in adding email alerts and other email integration, so it looks like may be revived for the 0.7.0 release cycle. I haven't yet reviewed Mike's code or design, and he has unfortunately gone missing, but it will most likely be the starting point for any implementation that is created. -- Ryan 04-Jun-2008 22:00 PDT

Can we get this into the Roadmap? It's a killer feature in a project environment. Email is more push than rss. -- Antony Stubbs 25-Jun-2008 19:51 PDT

September 2012 Update

Following changes in branches/cclavadetscher

  • New class for E-Mail sending is ready.
  • Configuration page for E-Mail settings is ready, including a button for testing the settings.
    • This required modifications in the admin.jsp to return to the active tab after saving.
  • Issues:
    • changing the configuration is not immediately active: Solved. The problem was in the WikiMail class intantiating the session getting the default instead of a new one each time.
    • some texts are displayed with question marks: Solved. WikiMessage expects a key mapped to a text in

Next steps:

  • Use mail mechanism for "forgotten password" use case.

Additional information: I created a free mail account on that could be used for testing, if applications don't have a SMTP server yet and are not behind a corporate firewall:

requires authentication: yes
use ssl                : yes
host                   :
port                   : 465
username               :
password               : 115cc03e2f8404e5079aaf7cd21b35f5
reply address          :

I am afraid that I won't be able to finish all before the release in the few hours that I could spend on the project. In that case this will be a feature for 1.3.1 (or something like this). From Saturday I will be away until the beginning of November. I will resume work after that and comment here how far I have come before I leave.

-- Charles 26.09.2012 17:44 CEST

Thanks as always for all of your work on this - it's very appreciated. I'll make sure I do some review of the code before November and will also try to help out with development if time permits. -- Ryan • (comments) • 26-Sep-2012 21:20 PDT

I could solve the two problems that I mentioned above. I was thinking of adding a property to enable/disable mailing. If a mail server is not configured, this property could be used to hide/modify those parts of the application that depend on it. For example the "Reset password" Button in the login page would not be visible. Does it make sense?

An "enable/disable" toggle makes sense and would provide an easy way for admins to temporarily turn off email in cases where it was being abused, for example. -- Ryan • (comments) • 28-Sep-2012 09:01 PDT

I added the toggle checkbox and committed the last changes to branches/cclavadetscher yesterday and this morning (the server was not reachable, so that I document all at once now). Here are some screenshot of the mail setting page.

Before enabling the service there is only one checkbox:


Clicking on it will allow entering the mail server information (notice that this settings are real, see above for the password, and could be used for testing from anywhere):


When the data is available, the admin can test the settings clicking on "Send test mail". This will send a mail to the address defined in the account of the logged in user:


Usually mails are delivered immediately:


All right. I will soon be away on holidays and won't be able to continue on the task until the end of October. If you find time to review the code it would be great. The next steps will be to use the service to implement features. I guess that in some cases it will also be a good idea to add additional enabling for the single features. An admin may want to enable password resetting, but not force people to confirm their mail address during registration.

See you. -- Charles 02.10.2012 08:40 CEST

November 2012 Update

Hello. I am back from holidays and plan to resume some work on this task. Did you find some time to review the parts that I already implemented? My next step would be to get into the use case "forgotten password". I will have a look at the best practices and propose one or more solution to it. Procedure ok for you? -- Charles 02.11.2012 14:34 CET

Unfortunately I've been a terrible, terrible project lead during this release cycle, and while I have a few good excuses (ahem) I really haven't been doing my job. That said, I don't want to slow you down, so since your code has been good and the email changes will have a lot of time for testing before the next major release, I'd suggest you move ahead as you see best, and I'll review it as time allows. -- Ryan • (comments) • 04-Nov-2012 19:03 PST
Wow. Yes, quite an impressive excuse. I wish you good luck as it seems that today there will be a hearing. -- Charles 05.11.2012 10:20 CET
Hello. Last week I was informed that I am one of 400 that have been laid off by the company. So I had to switch priorities. I will try to get back on implementation as soon as the situation is stable. Sorry for the inconvenience -- Charles 21.11.2012 11:49 CET
I'm sorry to hear that. JAMWiki 1.3 has been delayed due to my own real life issues, so hopefully we'll both be able to resolve those problems quickly. -- Ryan • (comments) • 23-Nov-2012 11:03 PST
Just a short update on this: I will start on March, 1st 2013 at the Swiss Economic Institute (a part of the Swiss Federal Institute of Technology in the position of Database Engineer with main focus on PostgreSQL. As I have seen your problem is progressing, too -- Charles 00:26, 04 February 2013 (PST)

December 2012 Update

Hi Ryan. I implemented the forgot password feature and commited the changes to my branch (branches/cclavadetscher). The branch is synchronized with trunk, but I added a comment which files are relevant for the use case. In the next days I will document the changes in a new section "E-Mail based services" in this document so that the strategy becomes clear. Bye -- Charles 08.12.2012 15:55 CET

Thanks! Given the delays to JAMWiki 1.3, I think it probably makes sense to try to include this feature in that release. A few comments based on a quick review:
  1. If possible, try to separate commits by functionality, so that instead of a single commit for a new feature and a merge it would be two separate commits; doing so makes reviewing changes a lot easier.
Sorry, yes. I was aware of the fact that this could be a problem, but forgot that svn commits can be done selectively. I will change that practice to make your life a bit easier :-)
  1. It might make sense to use a random number (instead of the encrypted password) for the challenge key and to then store that in the database, just because there is always paranoia around passwords. If we're storing the challenge key we should probably also store the reset request date, and then time out the ability to reset the password after a certain amount of time - say, two hours, and also record the requesting IP for security purposes.
Actually I wanted to avoid changes in the database. The effort of abusing this feature to get access to the system as logged in user is comparable to trying to break the password itself. The only issue is that there is no time constraint. I can change this and use the database, as most (if not all) systems do. I suggest that the challenge in the DB is deleted after the user has changed his password (normal case) or after the user logs in using his normal credentials for the case that somebody triggered the process for this user (abuse case). This way there is not an urgent need to run a maintenance process to delete all older entries that were never used.
If we use the DB for storing the challenge, I would suggest to extend the jam_users table. MediaWiki stores the information for password resetting in the user table: The process there is completely different. They generate a temporary password and mail it to the user. The user then logs in with the temporary password and is redirected to a page where he must enter a new password. All in all I find the current implementation that we have more user friendly and is best practice in many web applications.
  1. I've seen this type of feature abused to spam someone with lots of emails in a short period of time, so it may also make sense to add a check to disallow an IP from making more than 2-3 reset requests in a 24 hour (?) period.
Good point. This makes actually the usage of the DB mandatory. I will give it some thoughts. I think that the expiration time of the challenge, the number of retries before temporary disabling the feature for an IP and its duration should be configurable by the wiki admin. Do you agree?
  1. Mediawiki uses "Special:PasswordReset" instead of "Special:LoginReset" so it would probably be best to follow that naming convention.
Ups. Yes, this is already done and commited to the branch.
Let me know if I can help out with this feature. My current plan for JAMWiki 1.3 is to wrap up all development and basic testing by the end of December with a goal of putting out the first beta during the first week of January. -- Ryan • (comments) • 20:22, 08 December 2012 (PST)
Thank you. I can probably invests enough time in developing the changes that you proposed. So the December deadline should be fine. With reviews you already support a lot. I don't underestimate that :-) See you -- Charles 09.12.2012 09:44 CET
Everything you've proposed above looks good to me. I agree that it would be better if we didn't have to change the database, but at the same time this is a feature that we definitely want to ensure doesn't get abused so it's probably worthwhile adding the extra columns to allow more stringent control. -- Ryan • (comments) • 17:24, 09 December 2012 (PST)

I started looking closer to the database changes and I suddendly came to an idea: Wouldn't the problem of spamming be solved if we enabled per default Captcha for the challenge request site? That would simplify matters quite a lot. Bye -- Charles 16.12.2012 17:15 CET

Captcha would definitely help and should probably be used no matter what. Unfortunately bots have been able to crack captcha in the past, although I haven't recently seen as many bots here that have broken it so perhaps the underlying implementation has been strengthened somehow. If you'd like I'm happy to implement any needed database changes, which would then leave you free to focus on the actual email implementation - that might be a good way to divide up work, so please let me know your thoughts. -- Ryan • (comments) • 09:00, 16 December 2012 (PST)

Yep. Another issue that I thought of is, that forcing the wiki admin to create key pairs on Google may impact the acceptance of the system creating an additional barrier that is not strictly necessary.

I was already quite advanced with the DB changes when I wrote my question yesterday and I finished and tested that today. Where I would be glad if you can help is adapting the admin page to enable the configuration of the settings challenge timeout, number of allowed requests before blocking IP and duration of ip blocking. For the moment I am using the default values for the implementation of the process. Bye -- Charles 02:46, 17 December 2012 (PST)

public static final String PROP_EMAIL_SERVICE_FORGOT_PASSWORD_CHALLENGE_TIMEOUT = "smtp-service-forgot-password-challenge-timeout";
public static final String PROP_EMAIL_SERVICE_FORGOT_PASSWORD_CHALLENGE_RETRIES = "smtp-service-forgot-password-challenge-retries";
public static final String PROP_EMAIL_SERVICE_FORGOT_PASSWORD_IP_LOCK_DURATION = "smtp-service-forgot-password-ip-lock-duration";

If the time is not enought this may also flow into a minor release after deployment of the 1.3.0 release.

Good news. I could find the time today to implement the use case. I committed all the changes to my branch. That means that I will also be able to take up the configuration part that I mentioned earlier this day, since I assume that you already have a lot to do. I think that I will need some help later for merging to trunk. In a dry run I have seen lots of tree conflicts (they come I guess from the redesign of the database access components, but I hoped svn would clarify the conflicts itself). I will add some description here tomorrow and possibly start the implementation of the configuration part. Bye -- Charles 07:30, 17 December 2012 (PST)

Let me know when you're ready and I'll do the merge to trunk. The conflicts you're seeing may be due to a need to merge trunk into your branch before merging your branch to trunk (basically, re-sync), but I can take care of it whenever you're ready. -- Ryan • (comments) • 17:37, 17 December 2012 (PST)

Ready for review/test

Implementation Notes

E-Mail support is a new feature as of JAMWiki 1.3.0. The classes that are used are the following:

E-Mail server


Is the class responsible for connecting to the SMTP server and send E-Mails.

The class expects a set of properties:

smtp-authentication    : Indicates if the SMTP server requires authentication. If set to true then
                         the values of smtp-username and smtp-userpass must be set as well. If set
                         to false those properties are ignored.
smtp-use-ssl           : Indicates that the SMTP server requires SSL. A well known server using SSL
smtp-reply-to          : The FROM address of the mail.  
smtp-host              : The host name of the SMTP server.
smtp-content-type      : text/plain or text/html (default at installation: text/plain).
smtp-address-separator : The character used to separate TO mail addresses in a String (default: ";").
smtp-userpass          : The password of the user sending the mail.
smtp-username          : The username of the user sending the mail (often the same as smtp-reply-to).
smtp-port              : The port of the SMTP server (default: 25).

There are other settings for enabling/disabling mail services altogether or individually. See the section below #Configuration Guide.

The class has a single overloaded method. Depending on your needs you may choose the one or the other. The actual implementation is done in the method with the highest number of parameters, i.e.

public void postMail(String[] toRecipients,
                     String[] ccRecipients,
                     String[] bccRecipients,
                     String subject,
                     String message,
                     String contentType,
                     String[] attachments)

The name of the parameters are self explaining and you will find more details in Javadoc. The list of recipients can also be passed as a single String with mail addresses separated by the value defined in the property smtp-address-separator. The overloaded methods all call this method with null parameters for those unused or where default settings must be used.

E-Mail Services

E-Mail services are features that require sending a mail to specific users. The number of features will probably increase with time and will be documented at their due time. Common to all of these services is that they can enabled/disabled individually.

Password Reset Service

Until JAMWiki 1.2.x users that had forgotten their password only could ask for resetting if they could contact the wiki administrator. Now users that have entered a valid E-Mail address in their account can request a mail with a link that leads them to a password resetting page.

The time of validity of the challenge created for this purpose can be configured by the wiki admin. The wiki admin also can configure how many tries should be allowed from one and the same IP address before locking that IP from this service. Finally, the duration of the lock can be configured as well. See below to learn how to configure your mail service.

Some changes in the database were required for the implementation of the password reset feature. The table jam_users, which contains the username, the hashed password and an enabled flag (currently not used and set to 1 during registration) was extended with 4 attributes:

     Column      |            Type             |     Modifiers      
 username        | character varying(100)      | not null
 password        | character varying(100)      | not null
 enabled         | integer                     | not null default 1
 challenge_value | character varying(100)      | 
 challenge_date  | timestamp without time zone | 
 challenge_ip    | character varying(39)       | 
 challenge_tries | integer                     | not null default 0
  • challenge_value: is created on the fly when a user requests a password reset link mail. It is currently a number
    0 <= challenge_value <= Integer.MAX_VALUE

In the future the computation of this value may change. It has no dependencies to the system.

  • challenge_date: a timestamp indicating when a challenge was issued. This value is used in combination with the properties smtp-service-forgot-password-challenge-timeout and smtp-service-forgot-password-ip-lock-duration to control the step in the process.
  • challenge_ip: the IP address from where the request has come. This value is used to determine if an automated process is trying to abuse the system to spam wiki users.
  • challenge_tries: the number of requests after which, new requests from challenge_ip are rejected.

In normal situations the challenge_* fields are set to null and challenge_tries to 0. The values are reset after the user has changed his password or after a successful login. The latter can happen if somebody was requesting a mail erroneously.

The implementation is contained in:


Following changes were also necessary:


For the configuration of the service on the admin interface.


For the management of the password reset data.


For inclusion of the link to the password reset starting page.


To reset challenge data in the database after successful login.

Finally adaptations of SQL statements and classes dealing with the upgrade to JAMWiki 1.3.0. Details are on SourceForge in branch branches/cclavadetscher.

STATEMENT_CREATE_USERS_TABLE: Addition of new fields for jam_users table creation during setup
UPGRADE_130_ADD_USER_TABLE_COLUMN_CHALLENGE_VALUE: To add column to jam_users during upgrade
UPGRADE_130_ADD_USER_TABLE_COLUMN_CHALLENGE_DATE: To add column to jam_users during upgrade
UPGRADE_130_ADD_USER_TABLE_COLUMN_CHALLENGE_IP: To add column to jam_users during upgrade
UPGRADE_130_ADD_USER_TABLE_COLUMN_CHALLENGE_TRIES: To add column to jam_users during upgrade
STATEMENT_SELECT_PW_RESET_CHALLENGE_DATA: To retrieve challenge data from jam_users
STATEMENT_UPDATE_PW_RESET_CHALLENGE_DATA: To update challenge data in jam_users
org.jamwiki.db.QueryHandler: New methods interface declaration for lookup and update of challenge data
org.jamwiki.db.AnsiQueryHandler: New methods implementation (QueryHandler) for lookup and update of challenge data
org.jamwiki.db.AnsiDataHandler: New methods interface declaration for lookup and update of challenge data
org.jamwiki.db.DatabaseUpgrades: Addition of add column statements for upgrades from previous versions

Test cases

  • The link "Forgot your password?" only appears when E-Mail service AND password reset are enabled. If any of those or both are disabled the link does not appear. Disabled mail services is the status after a new installation of JAMWiki 1.3.x or after an upgrade from previous versions.
  • The first page to appear only has an entry field for the username of the user requesting the password reset mail. Following errors are covered:
    • The user leaves the field empty.
    • The username does not exist.
    • The username exists, but has no E-Mail configured in his account.
    • Mail could not be sent.

If the username exists the system sends an E-Mail with a link to the address configured in the user's account. We assume that only the correct user can receive this mail. Clicking on the link will lead the user to a page where he can enter a new password.

Errors related to the link in the mail:

  • Challenge has expired.
  • IP address is locked from the service.
  • Following the link with random data for correct parameter names causes an error message to display.

Following errors are covered on the page, where the user can enter his new password:

  • Password cannot be empty.
  • Password is entered twice and the values must be identical.

In all cases when an error message is displayed the page does not allow anything more. If a user, e.g. has mistyped his username then he will have to return to the login page and click on the "Forgot password" link again to restart the process.

Configuration Guide

The mail support requires an accessible SMTP server and a mail account on that server that can be used to send mails. The mail server must be configured in the system settings Special:Admin. There are two sections:

  • E-Mail server settings: contains a flag to enable mailing altogether and to configure your SMTP server. Additionally there is a button that can be used to test the configuration. In order to use this, the logged in admin must have configured an E-Mail address in his account.
  • E-Mail services: A set of services, each containing a flag to enable the service and where this applies, entry fields for service configuration.


E-Mail server settings

The following information changes for all installation. Ask your mail service provider which parameters you must use. These are the same settings that you would use to configure your E-Mail client for that server.

The example shown above uses a account. A description of the settings for a client can be found here:

  • Enable E-Mail service: This flag enables mail services altogether. You will need to click this first in order to configure server information.
  • Mail server requires authentication: Some servers require authentication for sending mails. If this is the case for your server check this box.
  • Use SSL: Some servers require an encrypted connection using SSL (e.g. Check this box if this is the case.
  • Host: The name of the host.
  • Port: The port number. Default is 25, but particularly secured SMTP servers may use an alternative value.
  • Username: The username for your account. This is often the same as the E-Mail address.
  • Password: The password for authentication of your account. This value is only needed if the server requires authentication.
  • Reply address: The address that will appear in the FROM field of the recepient's mail client.
  • Default content type: Default is set to text. If a developer wishes to use a more appealing format, then switch to html.
  • Address separator: The character used to separate mail addresses of recipients, if these are passed in a single string.
  • Button "Send test mail": This will send a mail to the admin currently logged in on the wiki. It only works if you configured the E-Mail address in your account. If you are sure about your settings and don't want to test it, you can simply click on the "save" button. It is not mandatory for the admin to configure an E-Mail address for letting users have access to the service. Anyhow think that you may forget your password, too.

E-Mail services

Password reset

  • Enable password reset: Enable this service. Checking this box only will work if the mail service altogether is enabled (see E-Mail server settings).
  • Challenge validity timeout: The number of minutes that the challenge sent to the user by mail must be valid. If the user tries to use the link in his mail after this number of minutes, he will receive an error message. The counting starts from the timestamp of the request.
  • Number of requests before IP locking: In order to avoid spamming you can define the number of requests that are allowed from the same IP. If this number is reached, then the system refuses sending additional mails to the user until the duration of the IP locking is reached.
  • Duration of IP locking: The number of minutes that the system must refuse the service to the locked IP. The counting start at the timestamp of the last request.


I've merged everything to trunk but haven't done a thorough review. One question though - currently a user can change items on multiple tabs on Special:Admin and clicking "Save" will save them all, but that behavior has been changed so that changes are only committed for the tab from which "save" was clicked. Do you mind if I restore the old behavior? -- Ryan • (comments) • 21:33, 18 December 2012 (PST)

The enable checkboxes have a submit on click and I can remember that I had the issue that this operation returned the user always to the first tab. I don't remember however why I separated the storing functionality per tab. I guess that I found it confusing for users if they save something that they don't see on screen. Another problem was (but I caused it myself) that fields were not set correctly in the database, i.e. some values were overwritten with trash because they were not available in the post request to the server (not the same form. Before my changes all input fields were in the same form). Too bad I did not document that part good enough at the time. But getting back to your question, basically I don't have a problem if the save button saves data of all tabs and the user returns to the tab where he clicked the save button. It would just be necessary to test, if the phenomenon I described above does not show again.
Thank you very much for the merging. I will repeat testing with the trunk version. If you find any bug, don't hesitate to notify me. I look regularly at this page, and I should be able to find time for bug fixing before the beta release. Bye -- Charles 23:52, 18 December 2012 (PST)
I'll be traveling quite a bit over the coming two weeks, but will get the admin changes committed as soon as possible. I'll also try to do a more thorough code review. In the mean time, if there are any bugfixes or cleanups needed please feel free to commit them directly to trunk. -- Ryan • (comments) • 21:51, 19 December 2012 (PST)
Yesterday I committed a German and Italian translation update. Now I would like to create the mail subject and body from the ApplicationResources resource bundle. I was thinking of adding a method getMessage to the class WikiMessage, but it seems not as easy as I thought. Could you give me a hint where the resource bundle is loaded and how to access it to retrieve the message, i.e. the message from the bundle after the replacement of the parameters? -- Charles 06:10, 21 December 2012 (PST)
Is Utilities.formatMessage what you need, or something different? -- Ryan • (comments) • 09:04, 21 December 2012 (PST)
Yes. That is what I was looking for :-) Thank you. I made the changes to use the language resource bundle of the user default locale and committed it to trunk. Bye -- Charles 00:24, 22 December 2012 (PST)

I created a mail account. Then I noticed that there was a need for an additional smtp parameters. I see a huge advantage in the fact that everybody can set up a free mail account on gmail in a matter of minutes. So all wiki admins can enable E-Mail services quickly. -- Charles 01:01, 02 January 2013 (PST)

Hi. I made a short test of the admin save functionality after the last change (Restore legacy behavior so that you can again switch tabs and save settings from other tabs). Config is stored correctly and works fine. The only issue I see is that if a user saves data in a tab other than the "General settings" he always returns to "General settings". It may be a bit confusing, but is for sure not an issue that requires immediate action. This is more informational and it does not report a bug :-) -- Charles 04:40, 06 January 2013 (PST)

Remembering the tab when saving admin preferences has been on my "TODO" list for a while and (like many things) I've simply not gotten around to it - doh! The reason for restoring the old behavior was just to avoid confusing existing users - if people have gotten used to the fact that they can update on multiple tabs, changing that behavior might be an unpleasant surprise. I'll look into a quick change to remember the tab, which could probably be done fairly easily via Javascript.
Hopefully I'll get the beta release out today - I've been doing some testing with different databases since I don't want bad SQL to accidentally break someone's schema. Thus far HSQL, Postgres, and MySQL all seem to be OK for clean installs and upgrades. Once I've tested Oracle and MS SQL then I'll push the beta and send a release announcement. Thanks for all of your help! -- Ryan • (comments) • 08:48, 06 January 2013 (PST)