Question K 1.5.11: 'change username' javascript popup issue

You may want to look at this in Kunena Backend: Synchronize Users > Update user names in messages

I added it few versions back to make it at least possible to update usernames in the messages.

I have also plans to remove saved name in the message, when user has logged in and not used different name. But it's not high priority for me and needs some additional support in a form of plugin to work right.

Thank you, nikkie, for an excellent summary of the reasons for and against username change within Kunena. If I was ever in two minds about allowing username changes (which I wasn't :laugh: ) you've convinced me that there are other reasons that mitigate against it.

nikkie wrote:

I also agree that changing the username is adverse to the normal operation of Joomla. Additionally, as was pointed out, the main problem is that certain extensions, like Kunena, have designed one process or another based on the assumption that usernames won't change. For instance, in Kunena, posts are recorded with both a username and a userid, but Kunena takes a shortcut and uses the recorded username to display the user responsible for the post. This is technically incorrect and violates good normal form since the userid is already present and points to a username in the users table that just needs to be joined into the query that hoists this data. At that point it doesn't matter what the username is.

Kunena invited the situation by allowing the username change option without a method for properly keeping the identities straight on the screen in the wake of such a change or for refreshing the user session followed by a page refresh.

All things considered, it's probably not advisable to disrupt the underlying assumption that a username is not going to change. This keeps you straight with all the like assumptions that extensions are likely to make as well.

Yes, this looks as though this is one of those legacies of Fireboard that has remained dormant in Kunena for all this time and which, unfortunately, will probably find its way into K 1.6. For inasmuch as the solution is not just to allow a mechanism for user name change, Kunena's database design is not properly equipped to handle it. And so, because fixing the problem will require a sizeable rethink about how Kunena uses the username field, stored in the messages, this will also impact on all the modules and other Joomla extensions that people have developed for Kunena, too.

In effect, although we can mask the problems (by eliminating the web dialogs - whether they came from Javascript or PHP ... and I suspect they're PHP-generated) the solutions that emerge from this discussion will only be band-aids at best.

The data redundancy built into Kunena's database - i.e. storing both username and userid - reduces the number of database queries. On the one hand it delivers a small performance boost. Eliminating the data redundancy means that you could change username and the username change would seamlessly propagate throughout the message store. Does doing this mean that performance will suffer? I don't know. But, if this change is made, this won't happen in K 1.6. We would have to wait until K 2.0.

Interesting discussion. Short answer: don't allow your users to change username.

As a closing comment on this discussion, a proper solution has been implemented in K 1.5: see Kunena 1.6 - Eliminating the web dialog prompts