- Posts: 7245
- Thank you received: 566
Kunena 6.2.6 released
The Kunena team has announce the arrival of Kunena 6.2.6 [K 6.2.6] which is now available for download as a native Joomla extension for J! 4.4.x/5.0.x. This version addresses most of the issues that were discovered in K 6.1 / K 6.2 and issues discovered during the last development stages of K 6.2
Question K 1.5.11: 'change username' javascript popup issue
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.
Please Log in or Create an account to join the conversation.
nikkie wrote:
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.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.
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.
Blue Eagle vs. Crypsis reference guide
Read my blog and
Please Log in or Create an account to join the conversation.
Blue Eagle vs. Crypsis reference guide
Read my blog and
Please Log in or Create an account to join the conversation.