moderated Download members change proposal #suggestion


 

Hi All,

I am proposing the following changes to the CSV file generated when downloading a group's membership. Please let me know if these changes will be an issue for you.

Instead of numbers for the Status, Post Status, Email Delivery, Message Selection, Mod Status, and User Status columns, instead use the human readable versions that we use in the API. For example, Status of 1 would become sub_status_pending. Status of 0 would become sub_status_normal. 

The other change is that I will start including the member_id number as an additional column for each member, to help people sync memberships with outside databases.

Thanks,
Mark


Andy Wedge
 

On Wed, Jul 6, 2022 at 10:19 PM, Mark Fletcher wrote:
Instead of numbers for the Status, Post Status, Email Delivery, Message Selection, Mod Status, and User Status columns, instead use the human readable versions that we use in the API. For example, Status of 1 would become sub_status_pending. Status of 0 would become sub_status_normal. 
The current use of numbers doesn't cause me any concern but if it does change to more readable text then I think the explanation of the values can be removed from the column headings. What would be nice to have is an options to download the details in CSV and JSON formats like we do for database tables.

Regards
Andy


 

Mark,

The other change is that I will start including the member_id number as an additional column for each member, to help people sync memberships with outside databases.

Does the member_id change if a user unsubscribes (or is removed) and then re-subscribes? If so I would prefer the posterid value, which presumably would not change (as long as the user is using the same account).

Instead of numbers for the Status, Post Status, Email Delivery, Message Selection, Mod Status, and User Status columns, instead use the human readable versions that we use in the API. For example, Status of 1 would become sub_status_pending. Status of 0 would become sub_status_normal. 
 
Sounds good.

And would likely aid in consistency and be somewhat self documenting should new enum values ever get added (as has happened in the long-distant past).

Shal


 


The other change is that I will start including the member_id number as an additional column for each member, to help people sync memberships with outside databases.

Does the member_id change if a user unsubscribes (or is removed) and then re-subscribes? If so I would prefer the posterid value, which presumably would not change (as long as the user is using the same account).


I agree, poster_id primarily, but why not just include both id values as we do in the Members JSON export, so the CSV & JSON can not just be easily linked together between them but also with other group export JSONs and CSVs as well?  This way an admin can do user cross-group/subgroup analytics in a single database view with that extra group membership identifier, without it you're limited to one group only.

If we go that add-both route, we may want to use the same id column names in the CSV as in the JSON, or alternatively if we wanted to use "poster_id" (or whatever) in the CSV then change it in the JSON as well, whichever works best, I think it would be easier for the average admin if the id column names agreed between the two.

Cheers,
Christos


 

Hi All,

Thanks for the feedback. I've made the changes. I've included both User ID and Member ID fields.

Thanks,
Mark


Andy I
 

Being someone who likes smaller file sizes, I would prefer values such as "normal" or "pending", rather than "sub_status_normal" or "sub_status_pending", where the first two-thirds is redundant.  Having that string repeated 5000 or 50000 times, it adds up.  Also, "pending" is easier on the eyes.

Andy


Duane
 

On Thu, Jul 7, 2022 at 12:31 PM, Andy I wrote:
I would prefer values such as "normal" or "pending", rather than "sub_status_normal" or "sub_status_pending"
The "extended" names are used because that's what the API uses.  Otherwise, many people would have to learn two sets of descriptions.  If you don't use the API, it looks like wasted space, but is needed for consistency and clarity.

Duane


Bruce Bowman
 

On Thu, Jul 7, 2022 at 12:48 PM, Mark Fletcher wrote:
I've included both User ID and Member ID fields.
Mark -- The headings do not match the data in columns B-E

FYI,
Bruce 


Duane
 

On Thu, Jul 7, 2022 at 11:48 AM, Mark Fletcher wrote:
I've made the changes. I've included both User ID and Member ID fields.
There's a little glitch in the results.  The added field headings are just to the right of Email, but the data is 2 columns to the right.  That means the column for User ID actually has Display Name, Member ID has Username, Display Name is User ID, and Username is Member ID.  It's all there, just a bit scrambled.

Thanks,
Duane


Duane
 

On Thu, Jul 7, 2022 at 12:31 PM, Andy I wrote:
"normal" or "pending", rather than "sub_status_normal" or "sub_status_pending"
I just realized that a possible solution to this may be to change the column headings to the repetitive part and just put the variable part in the column.  Might be a little extra work for Mark to program it, but I think he's up to the task. ;>)

Duane


 

On Thu, Jul 7, 2022 at 11:03 AM Duane <txpigeon@...> wrote:
On Thu, Jul 7, 2022 at 11:48 AM, Mark Fletcher wrote:
I've made the changes. I've included both User ID and Member ID fields.
There's a little glitch in the results.  The added field headings are just to the right of Email, but the data is 2 columns to the right.  That means the column for User ID actually has Display Name, Member ID has Username, Display Name is User ID, and Username is Member ID.  It's all there, just a bit scrambled.

Oops. Fixed.

Thanks,
Mark 


Andy I
 

On Thu, Jul 7, 2022 at 01:47 PM, Duane wrote:
The "extended" names are used because that's what the API uses.  ...

I guess what you're saying is that the primary purpose of the CSV members list is as input to an API.  Yeah, that's not me.  I use it in Excel or OpenOffice, and I would think there are other users who use the CSV list for programs other than an API.  (Oh well.)

Andy


Duane
 

On Thu, Jul 7, 2022 at 04:24 PM, Andy I wrote:
I guess what you're saying is that the primary purpose of the CSV members list is as input to an API.
Not at all.  It's just more consistent to use the same 'description' for the same data in both situations.  Might help prevent misunderstanding for some that access the data both ways.

Duane