main@beta.groups.io

Re: Restrict "Set Moderator Privileges" Permission #suggestion #done

Charles Roberts

#24220

What WRB said, 2x........

My Opinion:

The GMF is supposed to be a place for Owners to go to seek help. At least that's my understanding. Too often, an OP receives a chastation for not crossing their "I's" or dotting their "T's".....or for saying something a "Moderator" doesn't like. Supposed to be Owners helping Owners, but rarely is a question answered by someone other than a "Moderator". I was a Helper Responder in an old Excel Newsgroup and I know how difficult it is for Non-teckies to ask questions, let alone understand the answers given by Super-Teckies......but it's the Super-Teckie Helper Responder's obligation to make the effort to TRY to communicate, and in no way should the OP go away feeling embarrased for asking.....(even if they ask the same dumb question more than once). Many times, in both beta and GMF, I've personally had to delete an entire "fireback" message I'd typed in answer to some unthoughtful response......

As suggested by WRB, POLLS, (with good questions), might be a good answer for suggestions/improvements/fixes....I love data over arguments.

This is where Chuck gets down off his Soap-Box now and partakes of additional medication.

My best to all

Chuck

Show quoted text

----- Original Message -----

From: txercoupemuseum.org

To: main@beta.groups.io

Sent: Sunday, February 16, 2020 12:57 AM

Subject: [beta] Restrict "Set Moderator Privileges" Permission #suggestion

On GMF under the topic "Membership Metrics” there was an exchange between a contributor and a moderator. Following that exchange, the contributor posted:

"And very silly of me to think that things might have improved in three months and "I" not notified.

The moderator responded:

"If something is wrong that can have serious effects, it's usually fixed within a matter of hours once It's been reported. Feature suggestions, once posted on beta, get added to the pile and may or may not be implemented. There was a feature added a couple of months ago that I requested in late 2015, so no need to get impatient. The best way, I think, to keep up with things is to read the #Changelog on this group when it's posted. Even better is to follow the beta group, but I know that not everyone will do that."

In my opinion some moderators are less than properly receptive to change. I don’t agree, so

I attempted to post this response to the above:

"I cannot envision “serious effects” greater than a moderator “permissions” that allows a moderator to demote or eliminate a group’s owner. This has long been under discussion. Reasonable consensus has been reached that this should be changed so as to be impossible. All argument against is based on “what if”, or “it’s been that way for so long, what’s YOUR problem.

I sometime wonder if all of us are speaking the same language. When an important “fix” is apparently “lost in the pile” a way to “bump” consideration and invoke higher priority would seem appropriate. Any suggestion(s) as to what to do when there IS just cause to get impatient?

WRB”

My “…message was not approved” for the following reason:

"While I agree that having that moderator permission allow any effect on owners is a bad thing, it is not in the same order of magnitude as something that blocks message delivery or otherwise impairs ongoing operation of the site.

There are enough topics discussing the Moderator permissions issue, we don't need to bring that discussion into this topic.”

OK, fine. I’ll bring this matter HERE for discussion. I believe it inappropriate that ANY moderator presume to unilaterally interfere with legitimate discussion on any “issue”. Whether we discuss it HERE or THERE, there MUST be an acceptable place and way for such discussion.

The subject above is the issue: "Protecting the original Owner from rogue co-Owners #suggestion”. Maybe this subject should have been submitted as a “Bug". It certainly isn't a “Feature”.

It should be obvious that certain existing moderators presently enjoy the power to demote or remove an existing or rightful owner SOLELY because Groups.io checkbox descriptions were unclear as to disclose the full range of actions thus “authorized”. These checkboxes are part of the initial process of setting up a group here. It’s just plain wrong not to timely disclose what is being thus authorized.

The result is an ongoing unnecessary and undesired threat to the internal harmony and even continued existence of each such group. It should be self-evident that ending this problem of long standing should receive support, not resistance; and higher priority from within Groups.io. After all, this problem was NOT created by those owners, but by Groups.io.

Opinions? Poll?

WRB

—

Re: Restrict "Set Moderator Privileges" Permission #suggestion #done

txercoupemuseum.org

#24219

Comments below in “< >”.

Best!

WRB

— 

On Feb 16, 2020, at 10:19 AM, ro-esp <ro-esp@dds.nl> wrote:

On Sun, Feb 16, 2020 at 01:10 AM, txercoupemuseum.org wrote:

There have been numerous opinions yes

 None of them (= moderator) privileges mention “also can demote existing owner”.

I cannot conceive WHY this time-bomb, which now is common knowledge and
undisputed. has not been defused.Probably because it requires a shedload of programming, and/or Mark hasn't gotten around to it.<Whether this sentence is started with the word “probably” or “possibly”, it is personal speculation which does not serve to move the discussion further toward resolution.  It presumes Mark does not prioritize suggestions in terms of those he deems most urgent.  

I think Mark is very aware that there are “back burner ideas” and “more urgent problems” in his “suggestions” pile.  Our discussions here on [beta] seem to be OUR only current way to help him perceive that resolution of THIS problem (of monitor-owner demotion or removal) is a “more urgent” one.>

Either THAT option should be deletedNo, it needs to be REFINED.<No.  Presently the description next to the selection box does not properly and fully disclose and warn that this selection allows a moderator so empowered to demote or throw out an existing owner.  You agree below that a “moderator should not be able to ‘demote' an owner*. 
 
“Refining” this option such that there is full and proper disclosure merely informs an owner of the danger implicit in checking that box.  It does nothing to eliminate that danger.  I think this checkbox option needs to be deleted or disabled immediately.  

Then, as time permits, an option to allow those related privileges as are NOT disruptive could be added back as deemed necessary or beneficial.  This more complicated task should be of lower priority.>

We seem to all agree that a *moderator* needs to be able to appoint another *moderator*, but should not be able to *demote* an *owner*.  The problem is that both fall under the same privilege now
<I respectfully disagree that there is any consensus whatsoever “...that a *moderator* needs to be able to appoint another *moderator*.>

the power for a moderator to demote an existing owner should be removed Once this is done, it is not necessary to appoint co-owners who would then
have the immediate power to demote or remove the existing acting
administrative owner. Whether a (co-)owner should have the power to demote a (senior) owner is a different matter.<Please.  “…(senior) owners don’t yet exist.>

My opinion is that (s)he shouldn't have that<Once more we’re diverted down a rat hole of speculation because we don’t yet have “…(senior) owners.>

, and I'm on the fence on whether a moderator should be able to demote another moderator<I think this privilege should be reserved to the owner (or perhaps a “sub-owner” if we create such)>

A moderator with all other owner powers can keep a group functional indefinitely.If (s)he can appoint another member to moderator and give him/her the necessary privileges, yes<One size does not fit all.  Groups with restricted membership have a much higher monitor work load in day-to-day function than those (like mine) who let anyone join.  I neither need nor allow moderators to appoint moderators.  That needs to be reserved to “upper management” function.  How “lower management, i.e moderators with greater or lesser powers, do things is each group’s obligation to work out for themselves.>

                                                           groetjes, Ronaldo

Re: Restrict "Set Moderator Privileges" Permission #suggestion #done

ro-esp

#24218

On Sun, Feb 16, 2020 at 01:10 AM, txercoupemuseum.org wrote:


There have been numerous opinions yes

  None of them (= moderator) privileges mention “also can demote existing owner”.

I cannot conceive WHY this time-bomb, which now is common knowledge and
undisputed. has not been defused.Probably because it requires a shedload of programming, and/or Mark hasn't gotten around to it.

 Either THAT option should be deletedNo, it needs to be REFINED. We seem to all agree that a *moderator* needs to be able to appoint another *moderator*, but should not be able to *demote* an *owner*.  The problem is that both fall under the same privilege now

the power for a moderator to demote an existing owner should be removed yes

Once this is done, it is not necessary to appoint co-owners who would then
have the immediate power to demote or remove the existing acting
administrative owner. Whether a (co-)owner should have the power to demote a (senior) owner is a different matter.
My opinion is that (s)he shouldn't have that, and I'm on the fence on whether a moderator should be able to demote another moderator

A moderator with all other owner powers can keep a group functional indefinitely.If (s)he can appoint another member to moderator and give him/her the necessary privileges, yes

                                                            groetjes, Ronaldo

Re: Deleting attachments when out of space #update

Mark Fletcher

#24217

On Sun, Feb 16, 2020 at 7:11 AM Bruce Bowman <bruce.bowman@...> wrote:

On Tue, Jan 7, 2020 at 06:58 PM, Mark Fletcher wrote:

Attachments will be deleted from the oldest messages first. The text in the messages will not be deleted, just the attachments themselves. I will delete enough attachments to get the group to 95% of their storage limit. After that, the process will run nightly to keep each group under their storage limit.
Mark -- Just following up on this. Per Friday's changelog, the attachment purges appear to have been implemented, but it's not happening in one of my groups.

I'm working through the groups and it's taking some time. It's not that it's a lot of groups, but the process takes some time for each message. Also, I'm going from most space used to least, so you'll be near the end of the list.

Thanks,

Mark

Re: Deleting attachments when out of space #update

Bruce Bowman

#24216

On Tue, Jan 7, 2020 at 06:58 PM, Mark Fletcher wrote:

Attachments will be deleted from the oldest messages first. The text in the messages will not be deleted, just the attachments themselves. I will delete enough attachments to get the group to 95% of their storage limit. After that, the process will run nightly to keep each group under their storage limit.

Mark -- Just following up on this. Per Friday's changelog, the attachment purges appear to have been implemented, but it's not happening in one of my groups.

I have 13% attachments, 38% photos and 58% files for a total of 109%. "Storage Limit Reached" (used to be called Out Of Space) is set to Delete Old Attachments. I am unable to upload additional files and photos, which is good. But the purge of oldest attachments has not happened, and I'm at a loss to explain why.

It's not causing me any actual hardship, but I thought you'd want to know. Please contact me off-list if you need the group name.

Regards,
Bruce

Restrict "Set Moderator Privileges" Permission #suggestion #done

txercoupemuseum.org

#24215

On GMF under the topic "Membership Metrics” there was an exchange between a contributor and a moderator. Following that exchange, the contributor posted:

Show quoted text

"And very silly of me to think that things might have improved in three months and "I" not notified.

The moderator responded:

"If something is wrong that can have serious effects, it's usually fixed within a matter of hours once It's been reported. Feature suggestions, once posted on beta, get added to the pile and may or may not be implemented. There was a feature added a couple of months ago that I requested in late 2015, so no need to get impatient. The best way, I think, to keep up with things is to read the #Changelog on this group when it's posted. Even better is to follow the beta group, but I know that not everyone will do that."

In my opinion some moderators are less than properly receptive to change. I don’t agree, so
I attempted to post this response to the above:

"I cannot envision “serious effects” greater than a moderator “permissions” that allows a moderator to demote or eliminate a group’s owner. This has long been under discussion. Reasonable consensus has been reached that this should be changed so as to be impossible. All argument against is based on “what if”, or “it’s been that way for so long, what’s YOUR problem.

I sometime wonder if all of us are speaking the same language. When an important “fix” is apparently “lost in the pile” a way to “bump” consideration and invoke higher priority would seem appropriate. Any suggestion(s) as to what to do when there IS just cause to get impatient?

WRB”

My “…message was not approved” for the following reason:

"While I agree that having that moderator permission allow any effect on owners is a bad thing, it is not in the same order of magnitude as something that blocks message delivery or otherwise impairs ongoing operation of the site.

There are enough topics discussing the Moderator permissions issue, we don't need to bring that discussion into this topic.”

OK, fine. I’ll bring this matter HERE for discussion. I believe it inappropriate that ANY moderator presume to unilaterally interfere with legitimate discussion on any “issue”. Whether we discuss it HERE or THERE, there MUST be an acceptable place and way for such discussion.

The subject above is the issue: "Protecting the original Owner from rogue co-Owners #suggestion”. Maybe this subject should have been submitted as a “Bug". It certainly isn't a “Feature”.

It should be obvious that certain existing moderators presently enjoy the power to demote or remove an existing or rightful owner SOLELY because Groups.io checkbox descriptions were unclear as to disclose the full range of actions thus “authorized”. These checkboxes are part of the initial process of setting up a group here. It’s just plain wrong not to timely disclose what is being thus authorized.

The result is an ongoing unnecessary and undesired threat to the internal harmony and even continued existence of each such group. It should be self-evident that ending this problem of long standing should receive support, not resistance; and higher priority from within Groups.io. After all, this problem was NOT created by those owners, but by Groups.io.

Opinions? Poll?

WRB

—

Make pending message Reject a claiming event #suggestion

Shal Farley

#24214

Mark,

It has happened a few times now that I've composed an explanatory note when rejecting a message, only to find when I completed the edit that the message had already been approved or rejected by another moderator.

Making Reject a claiming event would solve that using the same mechanism in place for editing pending messages.

Shal

Re: Restrict "Set Moderator Privileges" Permission #suggestion #done

Charles Roberts

#24213

I would appreciate if someone could explain the rationale to me that would make it reasonable for any Moderator to be able to demote any Owner, (or any Moderator senior to them).

Chuck

Show quoted text

On Feb 15, 2020 8:06 PM, Duane <txpigeon@...> wrote:

On Sat, Feb 15, 2020 at 06:10 PM, txercoupemuseum.org wrote:

A moderator will all other owner powers can keep a group functional indefinitely.
Incorrect as of now. If that moderator can't give someone else moderator status, it would only last as long as that moderator did - end of group. Many of us don't see it as a "time bomb" since we've got co-owners. It's worked fine the way it is for over 5 years. Any change would need to be well thought out and consider the consequences of the action. My preference is to not change anything, but I wouldn't have a problem if an additional permission were required for a moderator to demote an owner.

Duane

Re: Restrict "Set Moderator Privileges" Permission #suggestion #done

Duane

#24212

On Sat, Feb 15, 2020 at 06:10 PM, txercoupemuseum.org wrote:

A moderator will all other owner powers can keep a group functional indefinitely.

Incorrect as of now. If that moderator can't give someone else moderator status, it would only last as long as that moderator did - end of group. Many of us don't see it as a "time bomb" since we've got co-owners. It's worked fine the way it is for over 5 years. Any change would need to be well thought out and consider the consequences of the action. My preference is to not change anything, but I wouldn't have a problem if an additional permission were required for a moderator to demote an owner.

Duane

Re: Restrict "Set Moderator Privileges" Permission #suggestion #done

txercoupemuseum.org

#24211

Ronaldo, et al...

There have been numerous opinions contributes here under the above subject, under [beta] "Protecting the original Owner from rogue co-Owners #suggestion”, and under [GMF] "Absentee Owner Succession feature” and [GMF] "What if Owner dies?”, each addressing (at least in part) the common concern of succession of a single owner in case of unexpected demise, departure or extended disability (and what then to do).

There is no simple place to go or straightforward procedure specifically addressing the subject of moderators. Instead, we have to select a member by name, then click on “Role” after which the choices are “ owner Moderator” or “Member”. After choosing “ moderator”, there are no less than FIFTEEN optional “Permissions”, at least one of which permits a moderator to demote an existing owner.

FIVE of these have in parenthesis further information, i.e. “(also allows…). None of them mention (“also can demote existing owner”).

I cannot conceive WHY this time bomb, which now is common knowledge and undisputed. has not been defused. Either THAT option should be deleted or the power for a moderator to demote an existing owner should be removed such that this land mine in new group choices is defused. Either is effective, so whichever is easiest should be done.

Once this is done, it is not necessary to appoint co-owners who would then have the immediate power to demote or remove the existing acting administrative owner. A moderator will all other owner powers can keep a group functional indefinitely.

An so to the question of group leadership in case the Owner function is unexpectedly vacant, whether from unexpected personal emergency such as death or disability, or abandonment. In this regard, I think Groups.io needs to have a policy of requiring each group to have or select a single person as their contact for all official business.

This is a matter for Groups.io legal staff to contemplate. If it were made part of revised “Terms of Service”, all related uncertainty is eliminated. Banks, telephone companies, etc. do this annually and even more often. Not something we clients of Groups.io need concern ourselves with.

When this is done, concurrently Groups.io should go back to the place discussed in the second paragraph above. Following the “Role” of “owner (and before “Notifications”) there should be a place requiring an entry for an Owner/representative successor designation. This would be a blank where each group would be required to enter the name of a “contact” authorized to speak for the group in case of unexpected demise, departure or extended disability of a serving Owner.

That person would have NO power whatsoever pending actual demise, departure or extended disability of a serving Owner. Problems solved! NO “cans of worms!

WRB

—

Show quoted text

On Feb 15, 2020, at 4:10 PM, Jeremy H via Groups.Io <jeremygharrison@...> wrote:

My thought (as expressed on GMF) is that there should be certain 'Owner only' privileges: I would suggest they are (1) the ability to make/unmake owners; (2) the ability to delete or rename their group; and (maybe) (3) the ability to set up a 'will file', as to what should happen if they go missing.

Everything else can/may be granted to moderators, including the ability to make others moderator: one possible extension to moderator privileges is one to 'Set (for others) only moderator privileges that they have' (but not those they don't).

The issue of what to do when the only owner of group goes missing is a another can of worms: as I see it, this is a situation that can only be fixed by Mark/Groups.io support intervention, for which they should have a published policy (which might be to do nothing).

Jeremy
_._,_._,_

Re: Restrict "Set Moderator Privileges" Permission #suggestion #done

Charles Roberts

#24210

What he said!

Chuck

Show quoted text

On Feb 15, 2020 5:10 PM, "Jeremy H via Groups.Io" <jeremygharrison@...> wrote:

My thought (as expressed on GMF) is that there should be certain 'Owner only' privileges: I would suggest they are (1) the ability to make/unmake owners; (2) the ability to delete or rename their group; and (maybe) (3) the ability to set up a 'will file', as to what should happen if they go missing.

Everything else can/may be granted to moderators, including the ability to make others moderator: one possible extension to moderator privileges is one to 'Set (for others) only moderator privileges that they have' (but not those they don't).

The issue of what to do when the only owner of group goes missing is a another can of worms: as I see it, this is a situation that can only be fixed by Mark/Groups.io support intervention, for which they should have a published policy (which might be to do nothing).

Jeremy

Re: Restrict "Set Moderator Privileges" Permission #suggestion #done

Jeremy H

#24209

My thought (as expressed on GMF) is that there should be certain 'Owner only' privileges: I would suggest they are (1) the ability to make/unmake owners; (2) the ability to delete or rename their group; and (maybe) (3) the ability to set up a 'will file', as to what should happen if they go missing.

Everything else can/may be granted to moderators, including the ability to make others moderator: one possible extension to moderator privileges is one to 'Set (for others) only moderator privileges that they have' (but not those they don't).

The issue of what to do when the only owner of group goes missing is a another can of worms: as I see it, this is a situation that can only be fixed by Mark/Groups.io support intervention, for which they should have a published policy (which might be to do nothing).

Jeremy

Re: log activity when someone responds to a poll #suggestion

J_Catlady

#24208

Oh, I think you mean you can edit the poll after people have already voted to show who voted for what. That's pretty bad.
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu

Re: log activity when someone responds to a poll #suggestion

Duane

#24207

On Fri, Feb 14, 2020 at 10:05 PM, J_Catlady wrote:

Ok. That’s very good to know. I’ve been wanting to do an anonymous poll in my group but always thought it was not possible.

There's a very LARGE caveat. The poll can be edited so that the information is revealed! That might be considered a bug, or at least an undesired option. Once the "Do not show who responded to the poll" option is chosen, it shouldn't be changeable.

Duane

Re: Default database view #done #suggestion

Chris Smith

#24206

Perhaps, as someone else suggested, truncating HTML columns at a certain height might help.

However, in our particular use case we would like to hide other columns too. We just need to be able to display a few columns, then when the user clicks on a row they can view the entire record.

Thanks,
Chris

Site updates #changelog

Mark Fletcher

#24205

Changes to the site this week:

INTERNAL: Added additional monitoring of the search cluster.
INTERNAL: Switched over to a new Elasticsearch 7 search cluster. All of this work around search has multiple goals:
- The old search cluster was under-powered and running on older software, and nodes were prone to freeze up.
- Defining a new member index for a new member directory search.
- Switching the existing member list search to use the search cluster with the goal of allowing groups to add additional custom fields for members, which could be searched upon.
INTERNAL: Re-indexed all of our data in a new search cluster.
BUGFIX: Found a file descriptor leak in some networking code.
INTERNAL: Began deleting attachments in groups that are over their storage allotment.
CHANGE: Changed more instances of subscriber to member on the website.

Have a good weekend everyone.

Mark

Re: log activity when someone responds to a poll #suggestion

J_Catlady

#24204

Ok. That’s very good to know. I’ve been wanting to do an anonymous poll in my group but always thought it was not possible.

Show quoted text

On Feb 14, 2020, at 7:10 PM, Duane <txpigeon@...> wrote:

On Fri, Feb 14, 2020 at 07:29 PM, J_Catlady wrote:

That depends on the answer to "Do not show WHO who responded to the poll"? Does it mean, don't even show the mods? I was under the impression it just meant "don't show the group."
On the two I looked at, not even an owner or poll creator can see who responded, being truly anonymous (except for the hidden record that keeps track of each persons response in case they want to change it.) Keeping it from most members is covered by the "Only moderators and poll creators can view results and responders, regardless of whether the poll is open or closed." option.

Duane

--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu

Re: log activity when someone responds to a poll #suggestion

Duane

#24203

On Fri, Feb 14, 2020 at 07:29 PM, J_Catlady wrote:

That depends on the answer to "Do not show WHO who responded to the poll"? Does it mean, don't even show the mods? I was under the impression it just meant "don't show the group."

On the two I looked at, not even an owner or poll creator can see who responded, being truly anonymous (except for the hidden record that keeps track of each persons response in case they want to change it.) Keeping it from most members is covered by the "Only moderators and poll creators can view results and responders, regardless of whether the poll is open or closed." option.

Duane

Re: log activity when someone responds to a poll #suggestion

J_Catlady

#24202

On Fri, Feb 14, 2020 at 04:46 PM, Duane wrote:

I realized that if implemented, there should be no logging if the poll is set up for "Do not show who responded to the poll" is chosen.

That depends on the answer to "Do not show WHO who responded to the poll"? Does it mean, don't even show the mods? I was under the impression it just meant "don't show the group."

--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu

Re: log activity when someone responds to a poll #suggestion

Duane

#24201

On Thu, Feb 13, 2020 at 07:34 PM, Bill Hazel wrote:

Could "responded to poll" be added as an activity in the logs (group's member activity log, and individual member activity log)?

While researching something else, I realized that if implemented, there should be no logging if the poll is set up for "Do not show who responded to the poll" is chosen.

Duane