User Essentials [Paid] 2.8.4

Xon · Jan 10, 2017

Beanjam said:
The status display would be better handled with template changes instead, if that makes sense. It looks like right now when you disable Can Be Invisible for a user group, it changes every user's preference in that group to be visible. In my case, during testing I think I have just lost everyone's preference with no easy way to restore it.

The user's preference should be retained no matter what the Can Be Invisible setting is.

An example of where this would be beneficial is if you have a user upgrade that promotes a user to a new group where they get the additional privilege to set their own online status preference. If they choose to be invisible but then drop out of this group due to an expiring upgrade, even if they are upgraded again their preference of being invisible has been lost.

I definitely agree, and will look to get this into v2.7.0 which should be out with-in the next week or two.

HWS · Jan 10, 2017

Xon said:
I definitely agree, and will look to get this into v2.7.0 which should be out with-in the next week or two.

There is a use case for the current behavior (and if I remember correctly it was added as a requested feature by the original author of this add-on).

If "Invisible" is a perk for a special user group it should not last if the user leaves the special user group and should be reconverted to "Visible" (as this user has no rights to be invisible any more). If this user gains the special user group rights again later, he would have to reset his account to "Invisible" again manually. This needs to be explained to the users but should be no problem to understand since it is the logical behavior.

@Beanjam: Admins -of course- should be careful when testing.

Please do not remove this feature!

Xon · Jan 10, 2017

HWS said:
There is a use case for the current behavior (and if I remember correctly it was added as a requested feature by the original author of this add-on).

My problem with the feature is it can cause unexpected data loss if you don't know about it, and especially since the "invisible" permission isn't setup by default!

I'll add a configurable flag to restore the default behaviour, but it will not be enabled by default.

Anthony Parsons · Jan 11, 2017

Big problem with the reply ban access to own thread, your permission gives them access to every thread, regardless who created it.

Suggestion: this needs an ACP log for admins to monitor who is being reply banned by members with such permission, to ensure it isn't abused, considering its a mod feature otherwise.

Xon · Jan 11, 2017

Anthony Parsons said:
Big problem with the reply ban access to own thread, your permission gives them access to every thread, regardless who created it.

Yikes, I consider that a bug!

Xon · Jan 11, 2017

Xon updated User Essentials with a new update entry:

2.6.9 - Security fix

The "Manage reply bans within own thread" permission now only applies to own threads, instead of all threads.

Read the rest of this update entry...

VladiD · Jan 17, 2017

Hi @Xon - I tried to update 2.6.4.2 to the latest release, but the browser would keep hanging. Is this addon incompatible with large boards? Thanks!

Xon · Jan 17, 2017

equinox said:
Hi @Xon - I tried to update 2.6.4.2 to the latest release, but the browser would keep hanging. Is this addon incompatible with large boards? Thanks!

This add-on touches the xf_user table, but even with hundreds of thousands of entries this will be a should be a relatively fast change.

You can manually execute it via the following SQL;

Code:

ALTER TABLE `xf_user` MODIFY `useress_tags` MEDIUMBLOB;

This is required, as otherwise you can't disable this add-on without breaking user registration.

ENF · Jan 19, 2017

Bug popped up after last upgrade to current version, triggered on the register form/process:

(MariaDB 5.5, PHP 5.6.29, User Essentials 2.6.9, XenForo 1.5.11 - Some info below sanitized for privacy)

Code:

ErrorException: Undefined index: user_id - library/UserEss/XenForo/DataWriter/User.php:40
Generated By: Unknown Account, 43 minutes ago
Stack Trace
#0 ./prod/library/UserEss/XenForo/DataWriter/User.php(40): XenForo_Application::handlePhpError(8, 'Undefined index...', './prod/library...', 40, Array)
#1 [internal function]: UserEss_XenForo_DataWriter_User->_verifyUsername('username', Object(SV_ModEss_XenForo_DataWriter_User), 'username', Array)
#2 ./prod/library/XenForo/DataWriter.php(996): call_user_func_array(Array, Array)
#3 ./prod/library/XenForo/DataWriter.php(725): XenForo_DataWriter->_runVerificationCallback(Array, 'username', Array, 'username')
#4 ./prod/library/XenForo/DataWriter.php(643): XenForo_DataWriter->_isFieldValueValid('username', Array, 'username', Array)
#5 ./prod/library/XenForo/DataWriter.php(1009): XenForo_DataWriter->set('username', 'username', '', NULL)
#6 ./prod/library/XenForo/ControllerPublic/Register.php(370): XenForo_DataWriter->bulkSet(Array)
#7 ./prod/library/UserEss/ControllerPublic/Register.php(68): XenForo_ControllerPublic_Register->actionRegister()
#8 ./prod/library/XenForo/FrontController.php(351): UserEss_ControllerPublic_Register->actionRegister()
#9 ./prod/library/XenForo/FrontController.php(134): XenForo_FrontController->dispatch(Object(XenForo_RouteMatch))
#10 ./prod/index.php(13): XenForo_FrontController->run()
#11 {main}
Request State
array(3) {
  ["url"] => string(45) "https://sitename.com/register/register"
  ["_GET"] => array(0) {
  }
  ["_POST"] => array(15) {
    ["username"] => string(0) ""
    ["0919333481755d4ae209ed7ee560b902"] => string(10) "username"
    ["c4c93fabe73fa7737dbfa6b8e550a62f"] => string(24) "user@emailaddress.abc"
    ["7c82ed5d7930bb82b48e403d02f4efde"] => string(0) ""
    ["f0b6df0f750aef4e0eb85c79b8faac28"] => string(4) "sex"
    ["dob_month"] => string(1) "1"
    ["dob_day"] => string(2) "1"
    ["dob_year"] => string(4) "1900"
    ["1520798d227082b1779b533891508c1d"] => array(1) {
      ["mtm"] => string(0) ""
    }
    ["custom_fields_shown"] => array(1) {
      [0] => string(3) "mtm"
    }
    ["66e05cec8f620f7910371be058f294cd"] => string(16) "Time/Zone"
    ["captcha_question_answer"] => string(8) "Q&A Answer"
    ["captcha_question_hash"] => string(40) "86a0a0cf3a92146098c6931f88f8b2283612d8ee"
    ["_xfToken"] => string(8) "********"
    ["reg_key"] => string(32) "13dcf9161a40afa234ebd2c4a279abfc"
  }
}

Xon · Jan 19, 2017

Xon updated User Essentials with a new update entry:

2.6.10 - Bugfix update

Fix user registration when "Allow previous names" is disabled, bug introduced in 2.6.8

Read the rest of this update entry...

ENF · Jan 19, 2017

Xon said:
Xon updated User Essentials with a new update entry:

2.6.10 - Bugfix update

Read the rest of this update entry...

Thanks for the quick fix - verified that the error I reported above has now been cleared.

ENF · Jan 26, 2017

New bug, related to name change request: (Some info below sanitized for privacy)

Code:

Error Info
ErrorException: Undefined variable: user - library/UserEss/ControllerPublic/Account.php:201
Generated By: RequestingUserName, Today at 3:35 AM
Stack Trace
#0 library/UserEss/ControllerPublic/Account.php(201): XenForo_Application::handlePhpError(8, 'Undefined varia...', 'library/Us...', 201, Array)
#1 library/XenForo/FrontController.php(351): UserEss_ControllerPublic_Account->actionUserNameChange()
#2 library/XenForo/FrontController.php(134): XenForo_FrontController->dispatch(Object(XenForo_RouteMatch))
#3 index.php(13): XenForo_FrontController->run()
#4 {main}
Request State
array(3) {
  ["url"] => string(50) "https://thewebsitegoeshere.com/account/UserNameChange"
  ["_GET"] => array(0) {
  }
  ["_POST"] => array(0) {
  }
}

PHP 5.6.30 / XF 1.5.12 / MariaDB 5.x / Addon version: 2.6.10 (latest)

How to reproduce error:

> User requests name change.
> Request appears in Moderation Panel
> Admin clicks "Approve" - Page refreshes, nothing changes. (not expected function)
> Admin clicks "Reject" - Moderation Item is closed. (expected function)

Thanks for your attention to this.

Xon · Jan 26, 2017

@ENF I've sent you a PM on atelieraphelion.com with a version that should fix this.

ENF · Jan 26, 2017

Xon said:
@ENF I've sent you a PM on atelieraphelion.com with a version that should fix this.

Cheers, thanks.
I'll get to it later this afternoon.

markku · Feb 20, 2017

@Xon

User name change request just came to moderation queue.

I checked "Approve" and saved.

Nothing happened, it just reloaded the moderation queue, with the user name change still in the queue.

Tried multiple times to no avail.

No entries in server error log.

Latest User Essentials version.

This used to work fine, but recently I uploaded all our Essentials add-ons incl User Essentials to latest version, so now something has broke this feature.

How to fix?

Oh @ENF above had the same problem. @Xon, can you send me the version too, thanks.

Xon · Feb 20, 2017

@markku please PM me on https://atelieraphelion.com

Xon · Mar 28, 2017

Xon updated User Essentials with a new update entry:

Feature Update & add-on overhaul

This is a major rework of add-on used on https://forums.sufficientvelocity.com/ and https://forums.spacebattles.com/ for the last 4 months as the feature list and changes have evolved.

2.7.0 Changes:

Use template modifications instead of template hooks

Use hinted code event listeners

Minify redistributed javascript

Rebuild installer to be more robust and consistent between upgrades/new installs

Only add default permissions to the stock...

Read the rest of this update entry...

Freelancer · Mar 28, 2017

Recommend the following index changes for the Likes Given feature (Warning, may be slow):
Code:
ALTER TABLE `xf_liked_content` ADD INDEX `user_like_date` (`like_user_id` ASC, `like_date` DESC);

"Recommended" or "Mandatory"?

Xon · Mar 28, 2017

Freelancer said:
"Recommended" or "Mandatory"?

If your forum has tens of millions of likes, it is basically mandatory for this feature to be usable.

markku · Mar 28, 2017

Xon said:
Xon updated User Essentials with a new update entry:

Feature Update & add-on overhaul

Read the rest of this update entry...

Question, why are these options enabled by default when going to Thread Tools -> Edit Thread?

This goes for all threads by default.

And I don't have these settings enabled in Group Permissions for Registered group.

It sucks to uncheck these everytime I want to make an edit using the Edit Thread.

User Essentials [Paid] 2.8.4

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Similar threads

We value your privacy