Tom,

Here are a few thoughts that clarified things for me…..

All good, except:

2. This group was set up to avoid swamping the GMF. Given the number
of posts, that was a wise move.

That one is almost exactly backwards.

It is Group_Help and GMF that serve in part to avoid swamping beta, beginning when beta got too busy for Mark to keep up with.
https://beta.groups.io/g/main/topic/2268338

That appeal was only temporarily successful, and Mark had to reiterate it a time or two. Ultimately (so far) the Guidelines were introduced to clarify and structure topics in beta:
https://beta.groups.io/g/main/guidelines

The intent is that beta should be reserved for topics that only Groups.io (Mark) can act on (#bugs & #suggestions, primarily). The pricing structure, of course, falls squarely in the "only Groups.io can act on" category.

Group_Help and GMF act as user-to-user support for questions that a hive mind of knowledgeable users can answer. You know, until a sufficiently strong general AI comes along. I agree with what Mark Murphy and others have said: advice and opinion on coping with the pricing structure, as a group owner or a group member, falls into this category.

Shal

Hi folks,

I had to resurrect this, I think I may have come up with a fast and simple code-wise solution (he says, hopefully) for this that will cover and self-correct the resulting problems.  In short, change the current process into a timed self-expiring process which, if it doesn't get the expected confirmation link click within the time limit, it reverts back to the previous email address value.
 
In long, a research & testing by-product of this GMF thread of mine, namely whether on premium+ groups an admin can help a user recover from a typo-ed address change, (yes it can because of (a) below), helped me understand the current process flow.  There are two underlying problems which cause this issue, (a) the timing of the new address database write, and (b), no undo/Plan B when things go wrong.
 

(a)
Right now, the new address database write (and in effect site-wide change) takes place right away pretty-much after OK is clicked, before the member has a chance to click on the emailed confirmation link sent to the new address.  The write probably takes place when the confirmation email goes out or thereabouts.  Then, I guess the account goes to NotConfirmed by default and ...

- if the new address is legit and the member clicks on the emailed confirmation link (or if a premium+ admin confirms them) it removes the NC status and all is fine.
(b)
- if it was a typo/non-existent new address, when the Dave's-not-here reply to the confirmation email comes back, the account then changes to blue Bouncing and it will stay there since nobody will ever click anything on the other end.
- if a false positive, and more than likely the wrong recipient probably knows it is a mistake and will never click on the link, the account again "stays in limbo".  (if they do click on the confirmation link, then at least a group admin can sort it out with the member)
 
OK, IMO the (a) database write should be moved and take place when the user clicks on the emailed confirmation link as that process should really determine (confirm) if the new account is legit, hence the change should commensurately happen at that point; until then, we continue operating with the old credentials until we prove who we claim to be, or we continue using the existing credit card until we get the new one in our hands. But this fix would still not cover the other cases in (b).  That's where adding Plan-B comes in handy, as it can take care of both (a) and (b) cases, meaning no code change (et al) is needed to move the db write part as Plan-B will compensate for it regardless.
 
Here's the thing, when one changes their email address anywhere, it is more or less expected that they are already in front of a internet-connected device and that at the very least they have access to the new email account.  So I personally think that it's a reasonable expectation that the user will complete this changeover (including clicking on the emailed confirmation link) within a reasonable amount of time; 15 min? 30 min? 45?  So with this -do it in a reasonable timeframe- presumption then, for Plan-B, when someone initiates an address change, a user-specific "ChangedEmail" timer/timed process/thread/whatever is started which remembers the previous email address value and will revert back to it by default if not stopped in time.

-If the user clicks on the emailed confirmation link in the meantime before the timer expires, that click kills the timer and does everything else normally as it does now, and all if fine.
-If it was a typo/bad address/false positive but they won't click/whatnot, or no confirmation link click takes place, the timer will expire, at which point it will write back the previous (good) address, and all is again fine.

This will cover pretty-much everything that can go wrong, because the only thing that will stop the rollback from automatically taking place, is the user clicking on the emailed confirmation link.  (OK, also a false-positive and the (wrong) recipient clicked on the confirmation link would also prevent the rollback, but that would happen/happens now regardless, a group admin and the user have to sort it out)

So when a bad-address happens, the account will stay in limbo for only the timer duration then revert back, so all an affected member has to do is nothing but wait a bit and things go back to the way they were.  But even if it's a good address but part of a (forgotten) test, a false-positive address which the recipient is ignoring, a (premium+) admin member email address change gone wrong, etc, unless if the new email address recipient clicks on the confirmation link, things self-correct back to what they were.

Cheers,
Christos

On Sat, Jan 2, 2021 at 01:37 PM, Tom Madden wrote:

 

4. Mark’s expenses, what he needs to charge, and what he feels is a fair return for his efforts, are none of our business.

Hear, hear.
 
--
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

On Sat, Jan 2, 2021 at 10:23 AM, Mark Murphy wrote:

Happy New Year!

Thank you, Mark M. Ditto. 

maybe you can enlighten me.  Why do some forum members choose to try to silence others, when it’s so much easier to simply control what they receive?

I haven’t been able to see an obvious answer to that conundrum. 

 

 

I noticed that too. (I also noticed it in Drafts when the draft message is still empty. Maybe that's intentional but still seemed odd.)
--
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

While attempting to send a message to a member this morning (accessed using Send Message at the bottom of that member's page), I noticed that the Discard button on the page doesn't seem to do anything.  There's no draft created, but I can't leave the page using the button.  I think it used to take me back to their member page.

Thanks,
Duane

As I read this thread I get the feeling we’re overthinking the situation. Especially when we drill down into the minutiae of incremental costs, social “worthiness” of groups, and financial resources of individuals. Here are a few thoughts that clarified things for me…..

 

1. Mark has extend us the courtesy of advance notification of a price increase giving existing groups a chance to upgrade at the old rates. This will presumably give Mark an immediate cash infusion.

 

2. This group was set up to avoid swamping the GMF. Given the number of posts, that was a wise move.

 

3. Although Mark has asked for our thoughts, he has not asked for our permission. One hopes he will take our comments into consideration but he is not required to do so.

 

4. Mark’s expenses, what he needs to charge, and what he feels is a fair return for his efforts, are none of our business.

 

5. This is “groups.io”, not “subscribers.io”. We transferred from Yahoo as groups, not as individuals. Individuals do not join groups.io; groups do. Discussing ways Mark can administer individual subscriptions is pointless. That’s the group owner’s job. Mark doesn’t approve subscriptions, monitor topics, moderate “loose cannon” subscribers. Determining how (or if) to pay to maintain or upgrade to Premium from Basic is one more responsibility of a group owner. For existing Basic groups, that can be as simple as limiting uploads or attachments to keep memory usage below the 1GB limit.

 

Finally, Mark is not changing the rules while the game is underway. But when a new game begins on the 18^th, we get to play by the old rules while any groups joining after that date have to play by the new ones. This should be a tremendous advantage for existing groups, because new arrivals might be more inclined to find groups to join rather than start new ones. (Also should discourage a disgruntled member from setting up a competing group for spite.) All that potential “new blood” could be really valuable, particularly for large groups comprised of geographically dispersed members who share a common interest but seldom (or never) see each other. Such groups are often dominated by the owner and a handful of contributors, and they can wither when time takes its toll. (The groups. Nothing we can do to keep individuals from withering! I’ve tried…)

 

Just my thoughts, thanks for reading.

 

Tom Madden

On Sat, Jan 2, 2021 at 09:01 AM, Chris Jones wrote:

I removed my second membership's Set Moderator Privileges, .... The list of checkboxes had vanished, as had the ability to select Moderator Notifications. I then reversed the process and lo! my list of selectable notifications had reappeared.

I would say again, as before, that if this is happening, it's a distinct and even weirder bug. Toggling "set moderator privileges" on and off should have no effect on the mod's abiltiy to select relevant notifications. Turning it off should not wipe them all out. In any case, I am not seeing this at all, for some reason.
 
--
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

--
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

> which is a mod in my test group but with no privileges....

What am I missing?!?
A MOD with No Priveleges...
Cannot Moderate.

They would be as a Member.

BillSF9c

I just went through the whole sequence again, with the same results. I can't drink any more coffee or I'll be on the ceiling. (Have switched to tea;). I'll leave it to Mark and/or others to sort this out.

Bottom line: I have a non-owner moderator in my test group with no permissions who has the complete panel of notification options available in their subscription page. Toggling this mod back and forth between set-moderator-privileges on and off has no effect. The complete notification panel is available no matter what.

I'll leave it at that for now. I am concerned about this from a practical point of view because, as I said originally, I just promoted someone to moderator status in my group and I am concerned about her having the abiity to elect to see notifications she should not. So unlike in some cases where I comment in beta, it's not just an intellectual curiosity.
--
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

--
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

On Sat, Jan 2, 2021 at 04:43 PM, J_Catlady wrote:

If you, Andy, are doing the same sequence and seeing something different, maybe I just need another cup of coffee.

I have done similar tests and would support Andy's point. I have two memberships of someone else's test group, where as a general rule everyone has moderator status. Using my "main" membership I removed my second membership's Set Moderator Privileges, leaving other checked boxes unchanged. I then logged out, and logged back in using my second membership. The list of checkboxes had vanished, as had the ability to select Moderator Notifications. I then reversed the process and lo! my list of selectable notifications had reappeared.

One thought; when you changed the permissions did you remember to Save the change? I ask because I nearly forgot...

Chris

I do see the effect you note, Andy, in regards to the moderator permissions panel, which is as it should be - you should see the moderator permissions panel if and only if you have "set moderator privileges" permission. But it does not happen in my tests with the moderator notifications panel, which also is as it should be.

So maybe we are talking about two different things. I am reporting that the moderator notifications panel in the mod's own subscription page is not filtered according to the actual permissions that the moderator has, and I am requesting that it be filtered.
--
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

On Sat, Jan 2, 2021 at 08:43 AM, J_Catlady wrote:

and look at the member page.

more accurately: and look at the subscription page
 
--
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

I tested this again - caffeinated - and am still seeing exactly what I reported before:

1. I gave my test mod zero permissions - none - in my test group (including no "set moderator privileges").
2. I log in as the test mod and go to that same group and look at the member page. The complete notification panel is there and all notifications are available for selection.

So I am still reporting this as a bug, only because I thought Mark had said the filtering had been implemented before - I could be misremembering - and/or suggestion.

If you, Andy, are doing the same sequence and seeing something different, maybe I just need another cup of coffee. Are you sure you're going to the same group pre- and post-logging in as the non-owner mod?
--
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

"The fact that this topic has continued over 270 messages is evidence that Markis inclined to listen to his customers. has not yet decided to shut down this thread. "
Besides, it's so much fun! You know how to mute, right?

--
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

I totally get what you’re saying you’re seeing, but I have a mod with zero privileges - none - who still sees the panel when logged in. Which was why I said “any subset.” I’ll double check, as I said. I may not be fully caffeinated yet...

--
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

On Sat, Jan 2, 2021 at 02:42 PM, J_Catlady wrote:

ps I have to say, what you saw also sounds like not what we want or would expect.

That maybe the case. However your original assertion was that "Any mod, with any subset of permissions (including the null set), can elect to receive notifications for anything: pending members, pending messages, etc" and that is not the case as I see it because if they don't have 'Set Moderator Privileges' they cannot change the notifications they receive as they don't see the panel where those options can be set.

Regards
Andy