User Essentials

User Essentials [Paid] 2.8.4

No permission to buy ($35.00)
  • Thread starter Thread starter Syndol
  • Start date Start date
Fair enough. I was thinking there could be a list under the Users tab for Nicknames where we could associate the users with the nicknames.
Yeah, the tricky part though comes into play with generating the list when you start typing @Username. It's easy to add to the list but it's likely to conflict with other add-ons. Other possible conflicts include people registering names that are listed as nicknames for a user, adding nicknames to users that already exist as other accounts, and overwriting all the code that handles the alerts for mentions. These are just things off the top of my head. A few are easily avoidable by just disallowing the names to be used and such but you get the idea.
 
A few are easily avoidable by just disallowing the names to be used and such but you get the idea.
I feel you. You could definitely disable these two:

Other possible conflicts include people registering names that are listed as nicknames for a user, adding nicknames to users that already exist as other accounts,

I couldn't code a stick figure so you're on your own with that one.
 
Daniel Hood updated User Essentials - Enhanced Version with a new update entry:

2.6.0

What's New:
  • New user/user group permission for being able to manage reply bans in their own threads (default is disallowed).
  • New user/user group permission for the ability to hide their online status.
    • Everyone will be defaulted to off so you need to make sure to update this fairly quickly for the users that you still want to be able to go invisible.
    • People that are already invisible will be stuck invisible.

Read the rest of this update entry...
 
What exactly does
  • People that are already invisible will be stuck invisible.
mean? What if they're currently part of a group that can be invisible but then they are taken out of that group? Will they stay invisible? Will they be placed back into visible mode?
 
What exactly does
  • People that are already invisible will be stuck invisible.
mean? What if they're currently part of a group that can be invisible but then they are taken out of that group? Will they stay invisible? Will they be placed back into visible mode?
The permission controls their ability to toggle their visibility state. If they're invisible and lose the permission, they're stuck invisible. Likewise, if they have the permission and choose to be visible and then lose the permission, they will be stuck visible.
 
hmmmmm. is there a way to force invisible users who lose the permission to change back to visible? Basically, I want to allow only paid accounts to go invisible. If their paid account expires and they stay invisible, it defeats the purpose
 
@Daniel Hood , there have been 11 new releases of this add-on in 2015! IMHO for such an aged essential add-on this is way to much. This add-on should work perfectly out of the box (install and forget) and only have well thought through, perfectly integrated features. It should only be updated when it cannot be avoided or a new feature is absolutely worth it and requested by many customers.

You should deal with this add-on like Syndol did. Care about it a lot and only add features if enough people customers vote for them to be included. Sorry, currently it gets more and more bloated (which also raises the chance for bugs).

A new feature should only be integrated, if it has been very well thought through, discussed with the customers and coded with practicability in mind. It would have taken as little as 30 more coding minutes (and may be 15 more thinking minutes) to include the new feature in a way we could really use it. With removing the invisible status automatically if a users is moved to a user group which is not allowed to disable invisibility. If you do not remove the invisible status if a user is no longer allowed to have it, why should anyone ever this feature?

As a long term customer (bought the initial version from Syndol a very long time ago) I would like this add-on to continue to be an essential add-on for every XenForo admin. And you know, many professional admins do not like to upgrade each add-on once a month just for features, which cannot really be used.
 
I appreciate your feedback. I think too many updates beats out not enough updates though ;). Of these 11 updates, 4 were to introduce new features. The first two were 6 months apart and the last two were only a month apart. I appreciate maybe once a month isn't ideal. Also 7 bug fix releases may not be ideal but a few of them were direct conflicts with XenForo, 1 was for tapatalk (that update could have been pushed to tapatalk if I recall but I figured it was faster to put it in mine), Some of the bug fix releases would have been better pushed together, I get that. Unfortunately though they don't always get reported at the same time. I hate when bugs get reported the second after I release a new version. I know that nobody enjoys the update process.

You should deal with this add-on like Syndol did. Care about it a lot and only add features if enough people customers vote for them to be included. Sorry, currently it gets more and more bloated (which also raises the chance for bugs).
I care about all my products, and the customers. There's not a great way for customers to vote on features because not enough people will use any site other than this one. It's hard to keep track of most liked posts. A big difference is also that I have a renewal system in place so I feel more of an obligation to add features, in my mind at least. Before it was a one off payment so it was easier to accept that you got the features you paid for and anything else would be a nice surprise.

I know some of these features are bloat which is why I try to tie everything to options and permissions, if you want them, use them. If not, they aren't forced on you.

A new feature should only be integrated, if it has been very well thought through, discussed with the customers and coded with practicability in mind. It would have taken as little as 30 more coding minutes (and may be 15 more thinking minutes) to include the new feature in a way we could really use it. With removing the invisible status automatically if a users is moved to a user group which is not allowed to disable invisibility. If you do not remove the invisible status if a user is no longer allowed to have it, why should anyone ever this feature?
That's fair. I don't think you're off on your time and I'm likely to implement it this way in the next release. The problem stems from the fact that I don't administrate a forum that uses these features. I have no personal need for them. Therefore, sometimes, like in this case, I don't think about how exactly they will be used. I took the #1 most liked suggestion in the closed suggestions node and implemented it in a way I was thinking about it being used. I was thinking about it more in a staff type setting where staff are the only ones allowed to go invisible or special/premium members. What I didn't think about was how frequently people would be gaining and losing the permission, and here we are.

As a long term customer (bought the initial version from Syndol a very long time ago) I would like this add-on to continue to be an essential add-on for every XenForo admin. And you know, many professional admins do not like to upgrade each add-on once a month just for features, which cannot really be used.
I appreciate your feedback and opinions. I want to keep making this and the rest of the essentials series more and more... essential. I realize some of it may be bloat but I try to combat that with options and permissions.
 
hmmmmm. is there a way to force invisible users who lose the permission to change back to visible? Basically, I want to allow only paid accounts to go invisible. If their paid account expires and they stay invisible, it defeats the purpose

This is a big one :)
 
I've just made it on my forum so that as you lose your permission (either by directly editing the user's permission, the group losing permission, or them being removed from a group with permission) their invisible status will be set back to visible.
 
That sounds like maybe it should be its own addon as to not add a lot of complicated code bloat to this one since not everyone will use that.
Maybe it should. I posted about it in here because Daniel asked me to after I posted about it in his adding for tags.

As for the criteria of bloat, well, given the above block of posts that might it be the best thing to go on.
 
Sorry about the additional update. I made a mistake with packaging the past version. Big thanks to @Liam W for fixing it since I'm away from computers due to my daughters birth last night.
 
Top Bottom