Problems with upgrading membership (PM - limits)

[sangham.net]

Dear friends,

I have some "trouble" with the integration of upgrading possibilities.

To explain it a little: I have installed some memberships which allow more than the post depending memberships. The standard memberships have for example limited PMs. Now it seems that such was not considered maybe in regard of PMs.

I try to send a member a PM and get this message "PM could not be sent to 'memberX' as their inbox is full!".

To explain. The member once had taken a membership which includes unlimited PMs. Later while having (for example) 40 PM in his mailbox, he upgraded to normal membership.

Having taken on the membership with unlimited PMs again, he still is not able to receive PMs or better I am not able to send him PMs (for Admin, there is no problem to do such of course, but as normal member the error arises)

What does the database make in such a case? Could that have caused a problem in the database?

How to solve this problem?
If you have any idea, it would be great if you could help out in this case and please apologize the request if it brothers and takes your time.
( I hope this forum is the right place for it)

[LiroyvH]

What is the SMF version?

[sangham.net]

Sorry, I forgot. 2.0.4

Thanks!

[sangham.net]

Just that I do not lead on a maybe wrong path:

This user has taken also a Membership which has a limit on PM's. So he has a membership with no limits and limits.
As I found out for other permissions, they would be accumulated. Maybe that is not the case for the PMs amount as this is a prime permission set directly in the membership creation form.

If that was the case, how does it handle with different permissions set in the prime form. Does it follow the prime membership group setting in the member profile setting? Or does it follow other pattern.

So for example if the user has a membership with unlimited PMs and a membership with 5 PMs and makes the "5 PM membership" to his prime group, would it follow the set prime group? (as this has normally no impact on other permissions as far as I had seen and would be just accumulated to the highest level)

[sangham.net]

Okidok,

as a little tested, it seems like this follows the set prime membership group. So what ever membership you make your prime membership it does not only adopt the appearance put also the PM amount.
As all permissions are generally managed in additional permission forms, it is maybe useful to set this also in the permissions form but on the other side very useful as well, as the handling of "forbidden" in the permission settings has to much general impacts.

Nevertheless, please correct me if I understood something wrong, of if there is something that I misunderstood.

[sangham.net]

And then in goes Back...

it looks like that is not the case. So one last idea is that the permission of amount of PMs in the member-group is a permission which is chosen by the minimum of all memberships.



So as it looks like, your support in regard of the impact of this permission is very needed in my case. I am sure it is at least very simple.

Thanks!

[sangham.net]

A co-member of our forum was so kind to make some further proves and gave his time to make a good additional documentation of the "problem" (and I guess in a better English as well)

X-group (max. 5 PM)
Y-group (max. 200 PM)

Problem description 20130412-220400
With X-group adding Y-group, by automatically system assignment setting Y-group to the main group, the Y-group authorization is coming to access, but the PM limit of the Y-group group isn't set, the PM limit of the X-group authorization is still activ.
By leaving the X-group there isn't also any change for the PM limit. It still stays and reacts as it will be X-group fact.
Assumption:
The lowest PM-Limite should never be activ, if the lowest access authority group is not main group.
Reason for the assumption is, that if it should be in opposition to the assumption, there hast o have for ever the PM Limit tob e set of the lowest  PM-Limite of the ,,ordinary member" group.
Priority level low, of cause there is a workaround.

Workaround
If you are assigned only to « regular member » and « X-group » and wants to assign too the Y-group, then please leave the X-group and then send a PM to the administrator that he can assign you to the Y-group. If the Y-group then is assigned, please leave the group again and send again a PM to the administrator, that he can assign you again to the Y-group. Now the Y-group is your main group and if you want, aou can assigna gain the X-group but please don't change the X-group to your main group, otherwise your PM limit is set to 5 for the Yogi Group.

What happens here :

The Y-group has a PM limit of 200, the X-group of 5.
If the X-group is set as main group and the assignment to Y-group as main group will be done, the X-group PM limit is not dropped and the Y-group PM limit is not set.
If you leave the X-group, that means, that there is missing a programm step for the backtracking and so the assignment to the X-group PM limit, fomally main group)  is still in access.
There is no change, if you leave the X-group, the PM limit of X-group is still in affect.
So if the X-group is left and the assignment of the Y-group as main group is done, the problem still exists. And if you now leave the Y-group, the system is evaluating, which Limit has now to be set. There it finds for example the regular member group and sets it's limit. In this way the X-group PM limit comes overwritten, or the assignment to this limit cancelled.
So if now again an assignment to the Y-group as main group will be done, the PM Limit of the Y-group comes installed. If now the X-group will be assigned again and it will not be main Group, but Y-group, there it should be set the Y-group PM Limit, but this is not the case, the Problem still exists. Of cause this, don't choose X-group additional to Y-group, if you don't wants to be limited by X-group PM max. Limit until the Problem is solved. Thank you.

[Chalky]

Sorry Johann, but your friend is as wishy-washy at explaining the problem as you are.  I don't understand what you actually need help with.  I will however, try to summarise the problem as I best understand it and you can tell me if I'm close, ok?

You have a member who belongs to two membergroups.  One membergroup allows more PMs to be stored than the other, yet this member's inbox is showing full when the lower of the two limits is exceeded.  You want to apply the higher of the two limits.

Correct?

[sangham.net]

Dear ChalkCat,

thanks for your sympathy. Yes for sure, we are not the best in regard of he current language used and special vocabulary which is used under good involved people. Sorry, please apologize.

"One membergroup allows more PMs to be stored than the other, yet this member's inbox is showing full when the lower of the two limits is exceeded."

Yes.

"You want to apply the higher of the two limits."

No, I just like to find out if the setting of PMs amount is working different as the other permission. Usually the permissions will always add each other. So the higher possibility will count. In the case of PM limits it seems to be contrary. The lower counts.

And it seems that the issue is not solved by just leaving the limiting member group. It seems that there stays something in the cache, that allows the member not to reach a "better" situation even he leaves the group. Just if one gives up all addition memberships this problem is solved. Just my assuming, its a cache problem.

The further question would be, why is that permission setting on another level on another place like all other permissions, just to understand it for a procedure perspective.

Thanks a lot for your care!

[Chalky]

I don't know why that PM setting is where it is, but I guess it makes sense since it's a numerical permission rather than a simple yes/no checkbox.  Also, it's logical to have it in the membergroup settings so that it can be set differently for different groups.

If you think it's a cache problem, have you tried emptying your forum cache?  My first approach, however, would be Admin > Forum Maintenance > Recount all forum totals and statistics.  It looks like that could be the beast

[sangham.net]

Thanks for your care ChalkCat,

actually I wanted to change for assuming to understand a little more. The problem was solved after the member gave up every membership first.
It would be maybe difficult to assume if a member has such problems (not everybody requests or sees a "problem" as a problem). To make it like you told would be maybe a solution, maybe even the only, but difficult to execute.

Maybe somebody knows more about the reason and the function of the the PM limitation.

If it (just the cache) is the beast, we need to clean up the beat periodical.

Thanks for your effort and time!