User Essentials [Paid] [Deleted]

[The Dark Wizard]

Good idea. I'll add this option to the next version. The option will allow Admins and Mods to ignore the minimum characters and post creation grace period whenever editing a member's post, thus always logging the "Edited by".

To make it so edits by Mods can never be changed would be quite straight forwards to do, but is not something that most people want in my opinion.
To have it as an option to "lock" the post after an edit, is a little more complex, and so I would require at least 3 people to be interested in this before I will look into it any further.

Thanks for your feedback.

I would love this! I had a custom addon we made that did this but it had to be deactivated because it caused interference with User Essentials, we made the sacrifice but it was highly used on our site. It would be sweet to have it back !

 

[The Dark Wizard]

It would also be great if you could set which groups can see post edit history or not.

 

[Luxus]

I have a suggestion to make. The useressLastEdit container has no spacing to the messageContent container:


There are 2 solutions to this.

1) Replace

<span class="useressLastEdit">

with

<div class="useressLastEdit">

and add a margin-top to the .useressLastEdit CSS.

2) Just add a display: block and a margin-top to the .useressLastEdit CSS.

 

[craigiri]

Spelling error in your RM page here"
Post Edit History with the ability to comapre posts

compare

 

[Syndol]

The useressLastEdit container has no spacing to the messageContent container...

Fixed, thanks

Spelling error in your RM page

Fixed, thanks

 

[Syndol]

As there does not seem to be much interest in adding the 'lock post after edit' or 'double post' suggestions to this add-on, I just might make those as separate add-ons.

For now I can release an update with just the option to always log post edits made by Admins and Moderators. This will ignore the minimum characters option, as well as, the grace period user group permission on all edits not made by the post author.

Are there any other small suggestions or bugs to report before I release this update?

 

[MagnusB]

I would like it to do my laundry about once a week, but I can live with every other week.....

 

[Luxus]

Thanks for incorporate my suggestion to this add-on

Today I noticed that you can warn somebody publicly. A permanent note then appears above the post with the notice of the moderator:



I still think it's a great addition to the add-on if moderators can make public notes in a post that can't be removed by normal users. This way moderators can "soft-warn" people without actually warning them or just add important staff messages in a post.

Btw, the "lock post after edit" feature was not suggested by me. While it would be nice to have this feature I don't consider it essential.

 

[yavuz]

Yes I did, several times in fact. First posting to the original thread in the russian support site and then here via PC, with no luck. IMHO this is easily an essential feature.

The addon was automaticly updating the message with the previously send one and updated also the status. So your message would appear recently send. In short, your message would get bumped.

Maybe it got lost between messages. Is anyone besides me interested this addon to have a double post prevention function? Please raise your voice

 

[Syndol]

Syndol updated User Essentials with a new update entry:

Version 1.0.6
Works with the latest XenForo 1.1.3

What's new:

• Added an option to always log post edits made by Admins and Moderators. This will ignore the minimum characters option, as well as, the grace period user group permission on all edits not made by the post author.
• Fixed the margins on the 'Last edited by' message at the bottom of posts.
• Made a couple of tweaks to the edit history compare look.

Upgrade Instructions:

1. Upload the file 'Upload/library/UserEss/ControllerPublic/Post.php' to your server,...

Read the rest of this update entry...

 

[Arkshine]

I've a weird issue. I've updated to XF 1.1.3 and before UE to 1.0.6. After upgrading XF and looking if all was working fine, I've noticed that the edit message color is not right.
It seems in your useress.css file, @mutedTextColor is ignored. When I inspect the element with Chrome, it says the property value is invalid, which is weird, because @mutedTextColor exists.
By hardcoding the color, it works, but I wanted to know what happens. Do you have any ideas?

 

[Luxus]

I've a weird issue. I've updated to XF 1.1.3 and before UE to 1.0.6. After upgrading XF and looking if all was working fine, I've noticed that the edit message color is not right.
It seems in your useress.css file, @mutedTextColor is ignored. When I inspect the element with Chrome, it says the property value is invalid, which is weird, because @mutedTextColor exists.
By hardcoding the color, it works, but I wanted to know what happens. Do you have any ideas?

I can confirm this.

 

[Syndol]

Changing those color values to {xenroperty mutedTextColor} and saving the template should fix it, however, you will notice that once you view that template again the color value is back to @mutedTextColor

 

[Arkshine]

Tried by curiosity, it works yes. Thanks. Can you explain more about this issue ? just being curious to understand the mechanism and such.

 

[Syndol]

I have just emailed everyone an updated XML to fix this issue.

Tried by curiosity, it works yes. Thanks. Can you explain more about this issue ? just being curious to understand the mechanism and such.

I am not entirely sure. Perhaps someone in the know can enlighten us both.
It seems that when you now import an add-on the color properties require {xen property
but when you export the same add-on it saves them all as @mutedTextColor

 

[Markus]

It would be nice if the general users who have been given the power of opening and locking their own thread, could not unlock a thread that was locked by a moderator or an administrator. Other than this, I love this add-on, it's pure epic!

 

[Luxus]

I don't think that XenForo knows if a thread has been closed by a moderator or a user. Well, you would have to add a "staff-lock" and "member-lock" function I think. I highly doubt this will interest many folks.

 

[Syndol]

It would be nice if the general users who have been given the power of opening and locking their own thread, could not unlock a thread that was locked by a moderator or an administrator. Other than this, I love this add-on, it's pure epic!

That is a good point.
What you suggest can be done of course but would require me to create a new table to keep track of who locked the thread last as I do not wish to modify the xf_thread table.
If enough people want this feature then I would be happy to include it.

 

[duderuud]

That would be a must-have add-on! Moderators/admins must always have the last say...

 

[Syndol]

While I agree with the above, what happens when the reverse applies?
When a user locks his thread but a moderator opens it. Should that user be forced to entertain replies and not be able to re-lock it?
That seems to defeat the purpose of giving that user permission in the first place. What do you think?