INT Permission Type - Inverse Priority

[MrDeranged]

Hope that I explain this right as I'm NOT a developer (obviously) .

Seeing as the current implementation of the INT permission goes by the highest number, I suggest the creation of a 2nd type of INT permission for developers to use that will do the opposite and go by the lowest number.

Use case would be for any permission made for time delaying an action (in which a lower number would actually be of greater value)

For example, if there was an addon that delayed the time between posts:

• registered - need to wait 24 hours before making an additional post.
• registered + - need to wait 12 hours before making an additional post.

Having a lower delay time (12 hours) would be of greater value to a user.

Other than changing the users primary usergroup to registered + (which opens up whole realms of other issues) there is no other way (that I know of) to do this.

Or lets take the upcoming Name Change permission in XF 2.2 <edited as per @Chris D XF 2.2's name change delay function is implemented as a global option, didn't realize that when originally posting.>

For another example if I use an addon where a Name Change delay function is implemented as a permission:

If I want my users to be able to do the following:

• registered - change name every 365 days.
• registered + - change name every 182 days

there is no way (TIKO) to do this other than, once again, changing the primary usergroup.

I'm sure there are other use cases where an Inverse Priority INT permission would be usable, but those were the two off the top of my head.

 

[Sim]

I will note that until the upcoming username change system I'm pretty sure there was nothing in the core product that had an integer-based permission where "lower is better".

But we will shortly have a "Minimum time between username changes" where lower is indeed "better".

I am curious as to whether we have any changes to permissions calculations in XF 2.2, or whether the same "higher number trumps lower number" calculation still applies? @Mike ? @Chris D ?

If higher number trumps lower number still, then the only meaningful upgrade we could have is: "Normal" users can change every X days, while "Upgraded" users can change as often as they like (0 days).

 

[Chris D]

It’s a global option. It isn’t a permission. Pretty much for this reason.

There hasn’t been any changes to that for 2.2.

 

[Sim]

It’s a global option. It isn’t a permission. Pretty much for this reason.

There hasn’t been any changes to that for 2.2.

Ahh - I was originally going to suggest that it would be a global option rather than a per-user option.

 

[Joe Link]

For those of us who run sites which rely on donations (and associated benefits), not having the option to reduce permission times based on usergroup has always been a huge issue with XenForo.

 

[Sim]

For those of us who run sites which rely on donations (and associated benefits), not having the option to reduce permission times based on usergroup has always been a huge issue with XenForo.

What permission are you specifically wanting to reduce based on usergroup?

 

[Joe Link]

What permission are you specifically wanting to reduce based on usergroup?

A few of them, but to name one, post edit time.

 

[Sim]

A few of them, but to name one, post edit time.

I don't understand why you would want to reduce that value when people are upgraded to a new usergroup?

The model for XenForo permissions is to give the Registered usergroup the minimum possible values/permissions and then you increase permissions from there by adding usergroups.

There aren't any numeric permissions in the core product (pre-XF 2.2) which work differently?

 

[Lukas W.]

There aren't any numeric permissions in the core product (pre-XF 2.2) which work differently?

It's been a recurring issue in add-ons. The core software has simply moved/placed everything that could profit from a lowest-first integer permission in options instead - minimum time between messages/threads to name just two.

It would just make sense to have it. Sure, you can work around with a more complex setup where your higher value usergroup gets replaced with a lower value usergroup, but it's unneeded and confusing overhead for people who are not as savvy in setting up permissions.

 

[Lawrence]

I think adding a new int permission that behaves opposite to another int permission will only add (much) confusion for most Admins, and not worth it for the few scenarios where the lowest value is needed. I would just use an option that lists user groups with a desired value below each user group that can be increased or decreased, and perform a isMemberOf via a switch statement that returns the value on the first positive hit. I've used this approach in the past with no issues.

The downside is (obviously) you would need an add-on, but then when members here want core functionality changed or a new one added, it normally takes an add-on anyway, so it's not much of a downside.

 

[Mr Lucky]

I think this would be useful. For example I have a group called "dodgy." They are users that I have restricted in what they can do.

(Posts need approval, no Conversations or attachments)

all set to never

However included in this group are users who don't understand the concept of editing a post without it making the whole thread a nonsense.

So post editing is also set o never. This leads to them asking me to fix typos 10 seconds after they posted. I'd prefer if they could have their edit time limit reduced, so for example a time limit with a tick or something that makes it override other groups time limit.

Yes, I know there is a workaround, ie give all users the lower time limit, create a group with the higher time limit and then just remove that group for users who should have the lower time limit.

But is not so elegant and doable in one go, because I have to give them the dodgy group and remove the edit time group.

 

[Mouth]

For another example if I use an addon where a Name Change delay function is implemented as a permission:

If I want my users to be able to do the following:

• registered - change name every 365 days.
• registered + - change name every 182 days

This, and several other add-on examples, are why this functionality is required. It's become quite a deficiency of xF.