Membership sys_acl_levels_members Redundant Data Excessively

I have been working on the default boonex payment module, and trying to not only get it to work, on upgrade, but also different little tweaks and adjustments, which were provided by AlexT and Esase over a period of time. Nothing has really been compiled in one place on how to get it all mashed up and working. The already available information, plus Deano providing additional information has set it on course with the default boonex payment module, and we are oh so close.

I have had to expire my membership level several times, in the due course of testing, to get things figured out. Now i am looking at the finalization steps, and come across something i need to get addressed. The table sys_acl_levels_members does not seem to ever purge.

user joins, though does not get assigned to the sys_acl_levels_members since it seems that 'if' membershipID = 3 (standard), then they are not written to the sys_acl_levels_members. That is all well and good, and have no qualms with that. What i am seeing though, is that based on sys_acl_levels, a member can upgrade to the highest level. So if you have three teirs:

Bronze | Silver | Gold, ultimately the member could in fact a database record on sys_acl_levels_members 3 Times for each entry if they were to upgrade to the upper most membership level. Alternatively, if a member opted for monthly membership access i.e. Bronze, then the end result would be that there would be 12 entries in the table sys_acl_levels_members.

So how this presents a problem --> just say we are talking about a site with 3K members, and each of these members are opted in for the monthly access level. 3000 * 12 = 36000 records that are now held on the sys_acl_levels_members table.

I am working on getting a purge script put together on this account, because there are in fact ~10K members, and would surely not want to deal with the wreck manually that would be required in order to clean this table.

even something as simple as running a query on the table and looking up DateExpires is a seeminly daunting task, since the timestamp requires that you are rather specific with your query. So my objective is to try the following

IF DateExpires < NOW() THEN MemExpired = 'Y' (compare NOW() to DateExpires)

Cron job to purge sys_acl_levels_members WHERE MemExpired = 'Y' (drop record)

looks like sys acl levels purging has been already fixed and will be included in 7.0.7

http://www.boonex.com/trac/dolphin/ticket/2469

 FP, great

 i just wonder how much more of this is running rampant through this script. i see we are two weeks past our projected 3 week release on the upgrade as provided from Andrew Boon :)

at any rate, thanks for the post.

I see this posts is 12 months old but thought I would make mention of something I just ran accross and see if there is a fix or one coming. This seems to tie in with acl data base claning noted with this string.

I know that promotional membership can be turned off and most seemed to have done so but in an effort to catch bots which make it through the rest of the membership enrollment system I have left it open. I find each day enrollments by bots and curious enough it seems they always enrolll as couples. Obviously when doing so it makes two database entries with seperate members ID's!  when I go to delete these entries they are wiped out of the members rolls and data base but the second person ID is left behind and not cleaned  in sys_acl_member_levels. As a result when logged in as admin viewing members the promotional member count still shows up the second person.

Has anyone noticed this and or is it being addressed in 7.1? any thoughts on possible data base damage by manually deleting these id's in SQL using phpadmin.

Thanks in advance