inherit
2671
0
May 14, 2013 14:40:03 GMT -8
Peter
🐺
10,615
February 2002
peter3
|
Post by Peter on Sept 30, 2020 9:39:57 GMT -8
Lynx is correct in that groups do exist in the dataHash object, and that members would need to login and perform some action the plugin can pickup on to be able to write to a super forum key. The issue with these stat collection plugins is usually dirty data, or users rewriting to the key due to them clearing offline storage (aka localStorage). So it makes them inaccurate. Edit: I like the discussion though. It's nice to see
|
|
inherit
173855
0
Apr 23, 2024 9:59:44 GMT -8
Texas
I check in every once in a while...
869
November 2011
petermaggio
|
Post by Texas on Sept 30, 2020 10:18:27 GMT -8
Peter, right, but in this case we can avoid dirty data fairly easily. The initial data would be spotty until people logged in, 'cause you can't access another persons groups without being an admin and going to their profile. However, this wouldn't actually require local storage as the data is stored in the hash already. So, if a user leaves a group or is forced out, the plugin immediately knows because there would be a diff between what they have in their hash vs what's in the super forum key. Then we can just show them a message lke "yay, you're group membership changed" and if they click on anything, we're allowed to update. Also, the plugin could be made even more accurate if you rooted out all the different ways a user could be added or removed from a group and forced an update whenever those events occurred. It wouldn't be totally accurate, but you could get pretty close on an active forum.
|
|
inherit
2671
0
May 14, 2013 14:40:03 GMT -8
Peter
🐺
10,615
February 2002
peter3
|
Post by Peter on Sept 30, 2020 10:42:02 GMT -8
Texas We are dealing with simple counters right (1 method of doing this plugin), there isn't anything complex going on. So in one case we could use increment / decrement per key for each group to prevent dirty data. Dirty data using other means is impossible to prevent, no matter how hard you try. Local storage is to prevent a rewrite. We are simply flagging that user as already incremented the counter. Remember these are simple counters, we aren't storing their id in the key, so we would have no way of knowing if they wrote to it or not, hence the local flag. Edit: Just to note, I am proofing it against people already being in a group. If staff were to be starting from scratch, or adding in from the group page themself, then it would be a different method. Basically we are talking different ways of doing this plugin.
|
|
inherit
217348
0
Jul 27, 2022 7:26:44 GMT -8
Lynx
5,779
January 2015
msg
|
Post by Lynx on Sept 30, 2020 11:15:00 GMT -8
I'm not Todge , Peter or Chris , but ... pb.data('user').group_ids will return an array of all the groups the current user is in. Doing an F12 and typing proboards.dataHash in the console even shows that the data is available on the home page of a forum (I tested it here on Support). If I'm stepping over the line here, just let me know and I'll back out quietly. EDIT: (I had used that in my Navbar Links plugin for which group(s) could see the added link.) EDIT #2: However, any kind of table or list to be built from this would require members to log on for the plugin to see if they belong to such a group and, if so, added to the list (which would most likely require a super forum key). A member being logged in would be the most dependable way of getting the information for all the groups to which they belong. ... but not the only way. For instance: if any logged-in member navigated to the Groups tab of a particular member, the groups that particular member is in could be gleaned from the page. BUT there is a problem with this that would need to be managed. If user/1 or any member of a group with the power to Edit Groups navigated to the Groups tab of a member who is in a Hidden group, we surely don't want to include that Hidden group in the key data. Also, if anyone navigated to a page like this: support.proboards.com/members?group=34&view=groupThat would be an opportunity for the plugin to add information to the key. There may be additional ways that could be employed to populate (and update) the key data which could be added, idk. But I think the biggest problem would be that it could take a great deal of activity on the forum in specific areas before the key data became a good representation of the membership in each group. It's possible the key data might never be a complete set. The coding for any of this is way above my pay grade, though. Yes, any member could go to another member's profile page and look at the Groups tab. However, the issue here is that pb.data('user') returns info on the current user. At most, you could scrape the profile, or mini-profile, and get another member's currently displayed group - but you could not get the whole list of groups they are in. If Member A was in 6 groups, being logged in as Member B would only get you 1 group (the currently displayed group) from Member A - even if Member B was Staff with the Edit Groups power - simply because pb.data('user') only gets the full info on Member B and not Member A. Member A would have to log in for the dataHash (and thus the plugin) to get all 6 of their group ID's. Lynx is correct in that groups do exist in the dataHash object, and that members would need to login and perform some action the plugin can pickup on to be able to write to a super forum key. The issue with these stat collection plugins is usually dirty data, or users rewriting to the key due to them clearing offline storage (aka localStorage). So it makes them inaccurate. Edit: I like the discussion though. It's nice to see Considering that, in most cases, Member Groups don't just get changed everyday (typically) - would dirty data be that much of an issue? Given that member groups aren't typically changed multiple times (as interpreted from the OP of this thread), wouldn't it be more of incomplete data for the count until all affected members have logged on?
|
|
inherit
2671
0
May 14, 2013 14:40:03 GMT -8
Peter
🐺
10,615
February 2002
peter3
|
Post by Peter on Sept 30, 2020 11:42:56 GMT -8
Considering that, in most cases, Member Groups don't just get changed everyday (typically) - would dirty data be that much of an issue? Given that member groups aren't typically changed multiple times (as interpreted from the OP of this thread), wouldn't it be more of incomplete data for the count until all affected members have logged on? It really depends on the way the plugin is created. Dirty data will always been an issue if more than one person has access to writing to the key. Granted, it can be greatly reduced depending on the way the plugin is created. There are a few ways of creating this type of plugin. 1. Simple key counters that get updated with increment / decrement, with local flagging of user to prevent rewrites. 2. Staff only writes to the key when adding / removing users. 3. Same as 1, but instead of incrementing counters, we store a little more data in the key to help keep things more accurate so we don't need local flagging. The most ideal way would be #2, but it's not retroactive, so if you have 200 members already in various groups you want to stat collect, then they have a manual job to force a key update. This method would be the easiest and most accurate. All it takes for dirty data is for staff member A to go to the groups page, get a phone call. While AFK, staff member B then updates the key with 10 new members added to the stat, then staff member A returns and updates the key before reloading the page. We can do things like timing out the page to prevent this, and on less active forums the chances of it happening are a lot smaller. For me, I don't want it to happen at all, regardless of the size of the forum, and that's why I want dictionary keys. I want to make reliable and accurate plugins.
|
|
Kami
Forum Cat
Posts: 40,029
Mini-Profile Theme: Kami's Mini-Profile
#f35f71
156500
0
Offline
Jul 24, 2021 11:48:29 GMT -8
Kami
40,029
July 2010
kamiyakaoru
Kami's Mini-Profile
|
Post by Kami on Sept 30, 2020 11:44:00 GMT -8
I think the problem would wind up being the plugin's intended purpose. If the plugin (in theory) would require all folks in the affected groups to log in, then for the purposes of a census for RP characters this plugin would not do the trick. RP forums use the census to encourage people to play specific character types and origins, and/or to determine whether or not they're accepting characters of a given type or origin based on the total number of them currently in existence. If the plugin requires everyone to login first, has dirty data, and has a risk of data being rewritten if people clear their local storage, then the plugin will not be useful to anyone looking to have a census for worldbuilding purposes as they would expect these numbers to accurately increment based on additions and subtractions to these groups. that's why I want dictionary keys. I want to make reliable and accurate plugins. Hero tbh. And also it would be nice if this information was just available regardless without needing to resort to a plugin since multiple groups is inherent to the software.
|
|
inherit
2671
0
May 14, 2013 14:40:03 GMT -8
Peter
🐺
10,615
February 2002
peter3
|
Post by Peter on Sept 30, 2020 12:03:14 GMT -8
Hero tbh. And also it would be nice if this information was just available regardless without needing to resort to a plugin since multiple groups is inherent to the software. It's an extra SQL query per page that needs to count the rows per group ID. So performance wise for a service such as this, I understand why it's not done. If you aren't acquainted with databases, then you can create some awfully slow queries while counting rows especially if you don't have good table structure. What could be done is a cached version of that number be wrote out available to JS. That's a possible option maybe.
|
|
Kami
Forum Cat
Posts: 40,029
Mini-Profile Theme: Kami's Mini-Profile
#f35f71
156500
0
Offline
Jul 24, 2021 11:48:29 GMT -8
Kami
40,029
July 2010
kamiyakaoru
Kami's Mini-Profile
|
Post by Kami on Sept 30, 2020 12:06:39 GMT -8
Hero tbh. And also it would be nice if this information was just available regardless without needing to resort to a plugin since multiple groups is inherent to the software. It's an extra SQL query per page that needs to count the rows per group ID. So performance wise for a service such as this, I understand why it's not done. If you aren't acquainted with databases, then you can create some awfully slow queries while counting rows especially if you don't have good table structure. What could be done is a cached version of that number be wrote out available to JS. That's a possible option maybe. I get that, though I still think that there might be a way to handle it specifically for the home page -- there are already multiple member statistics available so I feel like at least for the home page an extra query wouldn't be amiss; it would help with member stats (esp. for forums on which member groups are something that need to be documented) and is available on other providers. EDIT: On that note, for this particular instance / request, would there be a way to manually input some base information to start and then increment from there? EG, if I install this plugin and I have 40 members across 4 groups, how feasible would it be to input a base number of 10 per group and build from there from new members on? I feel like this is poopy still but a thought nonetheless.
|
|
#00AF33
Official Code Helper
19529
0
1
Nov 19, 2012 14:18:28 GMT -8
Todge
**
17,285
January 2004
todge
|
Post by Todge on Sept 30, 2020 16:21:55 GMT -8
If you want to eliminate dirty data, then, as Peter said, only allow staff members to update the key. The less staff you have the better in this case. You would still need to use 2 keys, one super forum key to store the counters and a super user key to keep track of which members have already been counted. If you allow members to update the key themselves as they log in, you would grab more data quicker, and the busier the forum the faster the data would be collected, but that also increases the chance dirty data, so in effect, the busier your forum is, the less accurate the counters are likely to be. Ideally you would have ONE staff member to trawl through all your member groups to collate the data without the risk of overwriting existing counts.
|
|
inherit
173855
0
Apr 23, 2024 9:59:44 GMT -8
Texas
I check in every once in a while...
869
November 2011
petermaggio
|
Post by Texas on Oct 1, 2020 6:16:08 GMT -8
Peter, are we allowed to do multiple push/pop calls based on a single click? I remember a discussion a while back about this but don't remember what the final verdict was.
|
|
inherit
2671
0
May 14, 2013 14:40:03 GMT -8
Peter
🐺
10,615
February 2002
peter3
|
Post by Peter on Oct 1, 2020 10:21:03 GMT -8
Peter , are we allowed to do multiple push/pop calls based on a single click? I remember a discussion a while back about this but don't remember what the final verdict was. Every call made is added to a queue and then that queue is cleared after 100ms. So there shouldn't be any need to worry about making multiple calls within the same action, as it will still be one request to the server. Maybe Chris can confirm that as well, as I haven't been through the source in quite some time, and I know me and Chris have spent quite some time going through it in the past. If not, I can check when I get more time tomorrow, or maybe tag a staff member just to get official confirmation so you don't waste your time. I think I am correct though, and I doubt that would have changed for v5 since I last looked.
|
|
inherit
252032
0
Apr 4, 2024 21:43:14 GMT -8
Retread
Tribbial Pursuit.
5,014
January 2018
retread
|
Post by Retread on Oct 1, 2020 12:04:47 GMT -8
Considering that, in most cases, Member Groups don't just get changed everyday (typically) - would dirty data be that much of an issue? Given that member groups aren't typically changed multiple times (as interpreted from the OP of this thread), wouldn't it be more of incomplete data for the count until all affected members have logged on? It really depends on the way the plugin is created. Dirty data will always been an issue if more than one person has access to writing to the key. Granted, it can be greatly reduced depending on the way the plugin is created. There are a few ways of creating this type of plugin. 1. Simple key counters that get updated with increment / decrement, with local flagging of user to prevent rewrites. 2. Staff only writes to the key when adding / removing users.3. Same as 1, but instead of incrementing counters, we store a little more data in the key to help keep things more accurate so we don't need local flagging. The most ideal way would be #2, but it's not retroactive, so if you have 200 members already in various groups you want to stat collect, then they have a manual job to force a key update. This method would be the easiest and most accurate. All it takes for dirty data is for staff member A to go to the groups page, get a phone call. While AFK, staff member B then updates the key with 10 new members added to the stat, then staff member A returns and updates the key before reloading the page. We can do things like timing out the page to prevent this, and on less active forums the chances of it happening are a lot smaller. For me, I don't want it to happen at all, regardless of the size of the forum, and that's why I want dictionary keys. I want to make reliable and accurate plugins. Hey PeterIf I understand correctly, it seems like #2 would only maintain accuracy for Hidden groups (which probably aren't of much interest for having a tally of members anyway). Open groups allow members to join and leave whenever they choose without Staff intervention. Petition groups allow Group Leaders (who aren't necessarily staff members) to admit members who Request to Join. And those members can leave whenever they choose without Staff intervention. Private groups do require Staff to place members in the group. But those members can leave whenever they choose without Staff intervention.
|
|
inherit
2671
0
May 14, 2013 14:40:03 GMT -8
Peter
🐺
10,615
February 2002
peter3
|
Post by Peter on Oct 1, 2020 12:15:39 GMT -8
Retread, Yeah, the plugin would need to hide some of the group functionality for regular members if we worry about dirty data. It just really depends if the plugin author is concerned It just depends on the plugin author at the end of the day. For myself, I would be attempting to reduce the possibility of dirty data as much as possible. Others may leave group functionality in place where members could leave when they want which would update the key.
|
|
inherit
2671
0
May 14, 2013 14:40:03 GMT -8
Peter
🐺
10,615
February 2002
peter3
|
Post by Peter on Oct 1, 2020 12:18:20 GMT -8
EDIT: On that note, for this particular instance / request, would there be a way to manually input some base information to start and then increment from there? EG, if I install this plugin and I have 40 members across 4 groups, how feasible would it be to input a base number of 10 per group and build from there from new members on? I feel like this is poopy still but a thought nonetheless. If the plugin was created in a way of it just being simple counters, then sure, you could have a field that can be set which would add towards the counter. Edit: In fact you could use this for any of the methods, but it's more likely used for the simple counter method.
|
|
inherit
Official Code Helper
65613
0
1
Apr 15, 2024 17:01:41 GMT -8
Chris
"'Oops' is the sound we make when we improve"
8,853
December 2005
horace
|
Post by Chris on Oct 1, 2020 14:56:37 GMT -8
I can confirm that 100ms queue is still in effect as of iteration combined_1047.js. All calls through proboards Ajax whether it be from library or multiple plugins/codes get the same delay treatment possibly to avoid some DDOS protection on triggering on the other end. Like Peter I haven't tested it lately but I do recall the sequence of order being preserved Edit:
Peter , are we allowed to do multiple push/pop calls based on a single click? I remember a discussion a while back about this but don't remember what the final verdict was. There was never a splice method added as promised but the workaround was to use multiple calls to achieve and was blessed by the coding gods.
|
|