Date   

moderated Re: Limit number of group aliases #suggestion

 


I remember/know of one case so far where a group wanting to move from Yahoo couldn't use the old group name.  A 'competitor' used it as an alias here just so the group moving couldn't.  There are liable to be more of these as GIO grows, so I hope Mark has something in place to handle it.  Allowing aliases isn't something I'd do at all because of the ensuing headaches, but a low limit should help.

I would agree with zero as the limit. Name squatting, like domain name squatting, is pretty evil.
 
 
This group alias issue is one of those bits that can get somewhat complicated.

If the aim of the no-more or limited aliases is to disable or discourage/curb squatting (malevolent or not for that matter), that can easily be defeated and the same net effect achieved by smartly creating & configuring groups, it would just be a bit more work; you can't (easily) stop/discourage someone knowledgeable from malevolently doing what that owner did, neither here nor on the net. 

You can however monitor them for recurring/suspect behavior.

I don't want to start a philosophical discussion on the ethics of group name (or domain) parking, there are valid points from both sides of the debate.  Plus after all, Mark implemented it here (and it has remained, so far), apparently it must have some type of value to him.  I don't know the origins, maybe it was just a convenience gifted to the paid groups due to an Enterprise request, I don't know; only Mark knows about the value of this feature to him and whether taking it away could present the potential impact of removing a convenience feature for prospective clients.  And if applied retroactively it could cause complications to existing Enterprise groups using it, so if that was to be avoided it may be yet another grandfathered thing now that needs tracking.

Cheers,
Christos

PS: One of my other selves, the green-eyed one, whispered to my ear "paid optional feature", but he's known to be a troublemaker, I don't know, maybe I should throw him out of the room.


moderated Re: Limit number of group aliases #suggestion

Glenn Glazer
 

On 01/30/2021 14:43, Duane wrote:
On Fri, Jan 29, 2021 at 04:07 PM, Bruce Bowman wrote:
Someone with malicious intent could even create hundreds just to fleece the system.
I remember/know of one case so far where a group wanting to move from Yahoo couldn't use the old group name.  A 'competitor' used it as an alias here just so the group moving couldn't.  There are liable to be more of these as GIO grows, so I hope Mark has something in place to handle it.  Allowing aliases isn't something I'd do at all because of the ensuing headaches, but a low limit should help.

Duane

I would agree with zero as the limit. Name squatting, like domain name squatting, is pretty evil.

Best,

Glenn

--
PG&E Delenda Est


moderated Re: Limit number of group aliases #suggestion

Duane
 

On Fri, Jan 29, 2021 at 04:07 PM, Bruce Bowman wrote:
Someone with malicious intent could even create hundreds just to fleece the system.
I remember/know of one case so far where a group wanting to move from Yahoo couldn't use the old group name.  A 'competitor' used it as an alias here just so the group moving couldn't.  There are liable to be more of these as GIO grows, so I hope Mark has something in place to handle it.  Allowing aliases isn't something I'd do at all because of the ensuing headaches, but a low limit should help.

Duane


moderated Re: Limit number of group aliases #suggestion

 

Bruce,

>>>
Premium/Enterprise groups can create an unlimited number of group aliases. Those names become unavailable for others to use. As GIO grows, this strikes me as increasingly problematic. Someone with malicious intent could even create hundreds just to fleece the system.
<<<

That can be/is a possibility but the good mitigating factor to that is that group aliases are not available in free groups so it would mean someone would have to pay $220 for a year (or monthly) in order to be able to do that "DNS parking", which lowers the probability it could happen.

But you are right, it can.  However,

>>> On that basis I'd like to suggest that 5 group aliases should be more than enough.

5 is too low IMO; regardless of retro-application of it or not, you would be handicapping certain types of groups which use the aliases for what they are useful over here, search keywords for finding the group***, and also prevent "competitors" from causing unnecessary group-related headaches.  For example, see attached, this printer hardware user group of mine, it covers the whole MicroDry (MD) line of ALPS printers plus re-branded ones.  As such, you can tell the aim/intent in my alias names, and by virtue of the whole model line +, it has to be big.  I'm sure there are other types of similar-purpose/function groups that do this, not just me or my type of group only.  I've also done a similar setup on another group which is a Special Interest Group which builds airliner model kits exclusively.

*** (I do know about the group description "hidden-text" trick but many don't)

But I have a relatively simple and easy suggestion to alleviate the concern without altering anything on current group aliases' functionality.  Here's the thing; alias creation/editing is an infrequent task, it may spike after (and a bit after) group creation, but after that, it should be relatively quiet; or the corollary, it may not happen until some time in the group's future and then go quiet again, same end result.  The point is, for all groups, any generated auditing data related to alias editing is not really going to be a large amount, therefore impact should be minimal/very-small on that end.  So,

- Create a "new"* table/place, GroupAlias_ActivityLog or whatever. (* "new" could be a literally-new one or use an existing table like the ActivityLog if it can support this)

- Add a few lines of code to the group-alias-deletion part, so it saves the pertinent info to the GroupAlias_ActivityLog, at the very least date & time, GroupID of where the alias was deleted from, OwnerID of that group, UserID & IsMod/IsOwner status of the person who did the deletion, and the alias text/pointer/whatnot; plus anything else that can be of use for this.

That's it, for now.  This would create the infrastructure needed and would start logging deletions.  Then we figure out how to get the warning light to blink.  My suggestion would be to create a reporting/trend-analysis script/job that at some specified interval depending on how quickly Mark would want to be given a heads-up.  It would compare all the group names that have been newly-created during that interval against the name of any GroupAlias_ActivityLog deletions during that same interval.  Also do a second same comparison but since-beginning-of-auditing-data this time.

1. If the count of matches (interval-only or since-beginning-of-log-data) is 0 all is kosher.

2. Otherwise break down the distribution of that count data based on the combinations of who did what and when, both for just the interval and since-beginning-of-log-data.  For example, how many new groups were created during the two timeframes:
- by the same owner, and the owner was the one who did the alias deletion. (more-or-less OK I'd think)
- by the same owner, and a mod was the one who did the alias deletion. (could point to the mod being cheeky/sneaky/whatnot, unbeknownst to the (possibly AWOL or non-savvy) owner)
- where the new group owner is neither the owner nor a mod of the alias-deleted group. (could be suspect)
- where the new group owner is a mod of the alias-deleted group and the owner was the one who did the alias deletion. (more-or-less OK I'd think)
- where the new group owner is a mod of the alias-deleted group and the mod was the one who did the alias deletion. (could be suspect)
- relationship between new group owner and their group membership in the group where the [owner/mod] alias deletion took place, or a member of any group of said owner/mod. (could be both I think)
And so on, you get the idea, whatever we may think could/would be suspicious.  For example, if the same group owner/mod seems to be consistently deleting aliases only for those to show up as new group names (at any point in time now or later on), by consistently totally unrelated people (i.e. they are not in a group the owner/mod are in), that would definitively be worth IMO having a look at, even if a cursory one at the very least.  It could be innocent (as me for example releasing and giving gratis one of the aliases in my example above to a "competitor" if I wanted to), but it could also be something more sinister afoot, including Bruce's concern, in which case some setup like this should help alert and eventually catch the perpetrator(s).

Cheers,
Christos


moderated Re: Rethink the messaging when user from banned domain tries to subscribe #misc #suggestion

 

The other thing I encountered when investigating (aka quizzing Nina about :) what a banned member or domain sees upon trying to join the group was a bad error message when a banned member actually tried to go to the group home page - for example, if someone had sent them a link to it. Nina informed us this morning in Docs that the error has now been fixed, because she had seen it as well and reported it to Mark. I tested this and found that now, when a banned member goes to the group home page, they see "You are not a member of this group." So maybe something like that could happen when an email address with a banned domain tries to apply to the group. It doesn't entirely make sense, because obviously, if they're trying to join the group, they already know they're not a member of it. But the same holds for a banned member trying to visit the group's home page. Perhaps the language could be adjusted slightly so that the same messaging could be applied to both situations, and so that an email addresss with a banned domain would not be explicitly told they can't join the group with that domain.

OTOH, I don't know from domains. I banned the one ex-member's domain because it was his private domain and I know that I didn't want him or anyone from his company joining the group. That is probably not the norm.
--
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


moderated Re: Non - Member Posts #suggestion

billsf9c
 

Remember the old clap-boards used to cause a sound matxhing vision to sync sound and movemnt in the film industry?

Sony upped that. Digital display with 60(100?). lights going around it to provide accuracy and visual cues, each.

If you want colors - ok. For the color blind and numatical folks, have a number inside it.

To save my battery and eyes, I am reading in white text and black background. This feature also skews colors even if they are text. Science also shows that eyestrain is caused by active white background of screens.

It would be nice to see a list of all these ideas with a way to vote for priority so important things are ranked and potentially addressed, sooner/est.

BillSF9c


moderated Re: Wrong error/bounce message when member tries to reply to a topic with a "tag only moderators can use" #bug

Bruce Bowman
 

On Thu, Jan 28, 2021 at 09:30 PM, Andy wrote:
At the least, the bounce message from Groups.io ought to tell the sender WHY the message could not be delivered to that topic. 
Andy -- Using GMail, I got this back:



So it does...eventually...tell you why the failure occurred. The main problem is that the failure is not 500-level, so your provider (and mine) keeps trying to deliver the message.

Hope this helps,
Bruce


moderated Re: Limit number of group aliases #suggestion

Malcolm Austen
 

As I was the cause of this being raised, I'll offer a view that 5 might be considered too few but I appreciate that there must be some restriction because they all restrict (or are restricted by) the overall (and finite sized) collection of group names.

For subgroups though, the limit can be higher (but still finite, just for sanity) because they come from a different pool.

Keep safe, Malcolm.

-- 
Malcolm Austen <malcolm.austen@...>

On 29/01/2021 22:07:12, Bruce Bowman <bruce.bowman@...> wrote:

Premium/Enterprise groups can create an unlimited number of group aliases. Those names become unavailable for others to use. As GIO grows, this strikes me as increasingly problematic. Someone with malicious intent could even create hundreds just to fleece the system.

On that basis I'd like to suggest that 5 group aliases should be more than enough.

Thanks for your consideration,
Bruce


moderated Re: Rethink the messaging when user from banned domain tries to subscribe #misc #suggestion

 

Not all transparency is good. We (purposely) don’t let people know when they’ve been banned from a grouo.


On Jan 29, 2021, at 10:10 PM, Starchild <sfdreamer@...> wrote:


"So do we want people with banned domains knowing that their domain is banned?"
    In my view: YES! Transparency is good. And I must say, banning entire domains sounds highly dubious to begin with, unless the whole domain is clearly just a vehicle for spam. In that case, I would hope some attempt is made to reasonably ascertain this prior to a domain being blacklisted.

Namaste,

((( starchild )))


-----Original Message-----
From: J_Catlady
Sent: Jan 29, 2021 9:04 PM
To: main@beta.groups.io
Subject: [beta] Rethink the messaging when user from banned domain tries to subscribe #misc #suggestion

Mark wrote this in the update today:

BUGFIX: In some cases, people on banned domains were allowed to subscribe to a group.
Banned domains came up for me recently when a former group member whom I had banned, and whose domain I had also banned, tried to resubscribe. I banned both him and his domain, not knowing exactly what the effects would be, but thinking I'd covered all my bases that way. I found out he'd tried to join through the log entry: "Non-member [x] attempted to subscribe with a banned domain via web." I assume that he was not logged in when he tried to rejoin, since had he been logged in, as a banned member the group would not even have been visible to him. (Thanks, Duane, for pointing that out to me in Docs. I had thought that only the Apply button would not be visible.)

Not knowing what happened, and what he saw, if anything, after he attempted to join with a banned domain, and wanting to find out, I tricked Nina into telling me in Docs by suggesting to her that it be documented. :-) As I'd hoped, she found out the answer and put it into the manual. From her message:
"
The Banning domains from a group topic in the Owners Manual now contains a note about what someone who’s not logged in and who tries to join a group from a banned domain sees (a notice that states “You are not allowed to subscribe to the group with that domain”).

I wonder whether this is what we want to happen. Banned users can't even see the group in question, let alone know they're banned from it. So do we want people with banned domains knowing that their domain is banned? In fact, had I known that this person would see that message, I would not have banned his domain. As I said, I wasn't sure what would happen but was trying to cover all my bases. Now that this is documented, it's not such a big deal (no surprises). But I wonder whether the same reasoning applies to a banned domain as applies to a banned user wth respect to letting them know that they're banned. I'm not sure what the alternative would be, since logging in does not apply to a domain, so unlike with a banned user, you can't make the group invisible to anyone from the domain. I just wonder whether the current messaging should be reconsidered somehow.

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


moderated Re: Rethink the messaging when user from banned domain tries to subscribe #misc #suggestion

Starchild <sfdreamer@...>
 

"So do we want people with banned domains knowing that their domain is banned?"
    In my view: YES! Transparency is good. And I must say, banning entire domains sounds highly dubious to begin with, unless the whole domain is clearly just a vehicle for spam. In that case, I would hope some attempt is made to reasonably ascertain this prior to a domain being blacklisted.

Namaste,

((( starchild )))


-----Original Message-----
From: J_Catlady
Sent: Jan 29, 2021 9:04 PM
To: main@beta.groups.io
Subject: [beta] Rethink the messaging when user from banned domain tries to subscribe #misc #suggestion

Mark wrote this in the update today:

BUGFIX: In some cases, people on banned domains were allowed to subscribe to a group.
Banned domains came up for me recently when a former group member whom I had banned, and whose domain I had also banned, tried to resubscribe. I banned both him and his domain, not knowing exactly what the effects would be, but thinking I'd covered all my bases that way. I found out he'd tried to join through the log entry: "Non-member [x] attempted to subscribe with a banned domain via web." I assume that he was not logged in when he tried to rejoin, since had he been logged in, as a banned member the group would not even have been visible to him. (Thanks, Duane, for pointing that out to me in Docs. I had thought that only the Apply button would not be visible.)

Not knowing what happened, and what he saw, if anything, after he attempted to join with a banned domain, and wanting to find out, I tricked Nina into telling me in Docs by suggesting to her that it be documented. :-) As I'd hoped, she found out the answer and put it into the manual. From her message:
"
The Banning domains from a group topic in the Owners Manual now contains a note about what someone who’s not logged in and who tries to join a group from a banned domain sees (a notice that states “You are not allowed to subscribe to the group with that domain”).

I wonder whether this is what we want to happen. Banned users can't even see the group in question, let alone know they're banned from it. So do we want people with banned domains knowing that their domain is banned? In fact, had I known that this person would see that message, I would not have banned his domain. As I said, I wasn't sure what would happen but was trying to cover all my bases. Now that this is documented, it's not such a big deal (no surprises). But I wonder whether the same reasoning applies to a banned domain as applies to a banned user wth respect to letting them know that they're banned. I'm not sure what the alternative would be, since logging in does not apply to a domain, so unlike with a banned user, you can't make the group invisible to anyone from the domain. I just wonder whether the current messaging should be reconsidered somehow.

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


moderated Rethink the messaging when user from banned domain tries to subscribe #misc #suggestion

 

Mark wrote this in the update today:

BUGFIX: In some cases, people on banned domains were allowed to subscribe to a group.
Banned domains came up for me recently when a former group member whom I had banned, and whose domain I had also banned, tried to resubscribe. I banned both him and his domain, not knowing exactly what the effects would be, but thinking I'd covered all my bases that way. I found out he'd tried to join through the log entry: "Non-member [x] attempted to subscribe with a banned domain via web." I assume that he was not logged in when he tried to rejoin, since had he been logged in, as a banned member the group would not even have been visible to him. (Thanks, Duane, for pointing that out to me in Docs. I had thought that only the Apply button would not be visible.)

Not knowing what happened, and what he saw, if anything, after he attempted to join with a banned domain, and wanting to find out, I tricked Nina into telling me in Docs by suggesting to her that it be documented. :-) As I'd hoped, she found out the answer and put it into the manual. From her message:
"
The Banning domains from a group topic in the Owners Manual now contains a note about what someone who’s not logged in and who tries to join a group from a banned domain sees (a notice that states “You are not allowed to subscribe to the group with that domain”).

I wonder whether this is what we want to happen. Banned users can't even see the group in question, let alone know they're banned from it. So do we want people with banned domains knowing that their domain is banned? In fact, had I known that this person would see that message, I would not have banned his domain. As I said, I wasn't sure what would happen but was trying to cover all my bases. Now that this is documented, it's not such a big deal (no surprises). But I wonder whether the same reasoning applies to a banned domain as applies to a banned user wth respect to letting them know that they're banned. I'm not sure what the alternative would be, since logging in does not apply to a domain, so unlike with a banned user, you can't make the group invisible to anyone from the domain. I just wonder whether the current messaging should be reconsidered somehow.

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


moderated Site updates #changelog

 

Changes to the site this week:

  • DOCS: Updates from Nina.
  • CHANGE: New, better favicon.
  • NEW: Group sponsorships can now be paid using Paypal.
  • BUGFIX: In the members page, if you did a new search while on the second or later page of an existing search, the pagination was messed up.
  • BUGFIX: Changed Elasticsearch sub search mapping to fix partial searches.
  • NEW: Prioritize 2factor authentication support requests to ensure they don't get lost.
  • BUGFIX: In some cases, people on banned domains were allowed to subscribe to a group.
  • BUGFIX: A banned user, going to a group page, would get endlessly redirected, resulting in a browser error.
  • BUGFIX: After adding an attachment when composing a message or reply, delay updating the attachment list for 3 seconds to allow S3 to propagate.
  • BUGFIX: Fix date display for 20th century dates for people with date formats not MM/DD/YY.
  • NEW: Add a link to the help center to the /static/welcome page, the default group welcome message, and the confirming confirmation email message.

Take care everyone.

Mark


moderated Re: Paypal support for group sponsorships #update

Malcolm Austen
 

This is good news Mark, thanks.

While I would like (love?) to have PayPal accepted throughout I can get by with annually opening up sponsorship for long enough to let the group treasurer put in enough from the group's PayPal account to cover the fees. What we don't (can't sensibly) have is a group credit card.

Malcolm.

-- 
Malcolm Austen <malcolm.austen@...>

On 29/01/2021 21:02:17, Mark Fletcher <markf@corp.groups.io> wrote:

Hi All,

I just pushed to production support for paying group sponsorships using Paypal. Please let me know if you see anything amiss.

(Adding Paypal support for group hosting fees will require much more work, as those aren't one time only charges. I don't know if/when that will happen).

Thanks,
Mark


moderated Re: Non - Member Posts #suggestion

 

Add me to the list of those supportive of ‘color recognition’ enhancements. 
AND fully supportive of the ‘dials’ argument in the P. S. 
Science supports each of these. 

On Fri, Jan 29, 2021 at 11:27 Christos G. Psarras <christos@...> wrote:


>>> Suggestion 1: Change the background colour

I also agree that, at the very-very least, changing the NM badge to some warning shade (red/maroon with yellow letters?) would visually help to alert the mod, if nothing else it could have prevented me from going into a rabbit hole trying to troubleshoot a similar NM issue a few days ago! lol 

The other reason I'm also supporting this is in the PS text, it diverges slightly so I put it there.


>>> Suggestion 2

I can see value in somehow marking/tagging/whatnot a group message depending on group function/purpose and settings, especially on research especially, news/opinion, (civil) political discussion, proposal, etc., any group function/purpose which you would want to visually identify posts coming from non-members (or non-experts?) for any reason.

The admins can always find out about that message/member if needed through the log, so at least that's covered. 

Regarding archive visual indication solution, regardless, logic would also have to be implement that happens right after member approval, to somehow retro mark/tag/whatever any already-posted nonmember-marked messages by that user before they were approved, only applicable to the UI of course, we wouldn't want to send out another same email message.  Depending on what's agreed, it may necessitate having a new status/badge/etc, XNM, "Ex Non-Member" (grey background light grey letters?), I don't know, but if we don't do some check like this, we would end up with the paradox of a (newly-approved) group member seeing their own messages online marked as having come from a [currently] non-member. :)

A XNM/whatever badge could also potentially be of use on groups which value membership status or message source in considering/weighing/rewarding content contribution.

Cheers,
Christos

PS: As a matter of fact, I would argue that we should take this and apply it further to the rest of the user badges, set special colors for them, or at least the most important ones; research has shown that old-school round steam gauges have one superiority to digital readout displays because, after you have familiarized yourself with the gauge layout and settings/values/"badges", it only takes a quick glance (or peripheral vision) to know where the dial is hence what setting/value/"badge" it points to, you don't have to "read" the instrument, or oven look directly at it; but you have to literally look and read the digital number display.  Anyone here who flies will attest to that, PPL to ATP, doesn't matter.  For the non-pilot folks, a quick test comparison between an old school round clock and your microwave's clock will show you that effect; and if you keep the clock within your nearer peripheral vision field, like let's say right next to your monitor, you can be looking a the monitor typing or whatnot, and still get a very good idea of the time without looking at the clock.  You can't do that with a digital number clock, you have to look at it and read it.

Similarly, right now in the sea of light blue, reading is your only lifejacket; but with different badge colors, after we memorize them, a quick glimpse/glance can warns us, plus tell us what's going on; one side benefit would be that if one had the whole member list onscreen, a scrolling sweep or two would give you a good idea of the [badge/user setting] group distribution, kinda of a visual self-reporting tool. 

Maybe I should start a new topic and reference this one.



moderated Limit number of group aliases #suggestion

Bruce Bowman
 

Premium/Enterprise groups can create an unlimited number of group aliases. Those names become unavailable for others to use. As GIO grows, this strikes me as increasingly problematic. Someone with malicious intent could even create hundreds just to fleece the system.

On that basis I'd like to suggest that 5 group aliases should be more than enough.

Thanks for your consideration,
Bruce


moderated Re: Paypal support for group sponsorships #update

Ken Schweizer
 

Can we use it to "sponsor" groups.io or just local groups?

Ken S

 

"And if any man shall take away from the words of the book of this prophecy, God shall take away his part out of the book of life, and out of the holy city, and from the things which are written in this book." God

 

From: main@beta.groups.io [mailto:main@beta.groups.io] On Behalf Of Mark Fletcher
Sent: Friday, January 29, 2021 3:02 PM
To: main@beta.groups.io
Subject: [beta] Paypal support for group sponsorships #update

 

Hi All,

I just pushed to production support for paying group sponsorships using Paypal. Please let me know if you see anything amiss.

(Adding Paypal support for group hosting fees will require much more work, as those aren't one time only charges. I don't know if/when that will happen).

Thanks,
Mark


moderated Paypal support for group sponsorships #update

 

Hi All,

I just pushed to production support for paying group sponsorships using Paypal. Please let me know if you see anything amiss.

(Adding Paypal support for group hosting fees will require much more work, as those aren't one time only charges. I don't know if/when that will happen).

Thanks,
Mark


moderated Re: Non - Member Posts #suggestion

 


>>> Suggestion 1: Change the background colour

I also agree that, at the very-very least, changing the NM badge to some warning shade (red/maroon with yellow letters?) would visually help to alert the mod, if nothing else it could have prevented me from going into a rabbit hole trying to troubleshoot a similar NM issue a few days ago! lol 

The other reason I'm also supporting this is in the PS text, it diverges slightly so I put it there.


>>> Suggestion 2

I can see value in somehow marking/tagging/whatnot a group message depending on group function/purpose and settings, especially on research especially, news/opinion, (civil) political discussion, proposal, etc., any group function/purpose which you would want to visually identify posts coming from non-members (or non-experts?) for any reason.

The admins can always find out about that message/member if needed through the log, so at least that's covered. 

Regarding archive visual indication solution, regardless, logic would also have to be implement that happens right after member approval, to somehow retro mark/tag/whatever any already-posted nonmember-marked messages by that user before they were approved, only applicable to the UI of course, we wouldn't want to send out another same email message.  Depending on what's agreed, it may necessitate having a new status/badge/etc, XNM, "Ex Non-Member" (grey background light grey letters?), I don't know, but if we don't do some check like this, we would end up with the paradox of a (newly-approved) group member seeing their own messages online marked as having come from a [currently] non-member. :)

A XNM/whatever badge could also potentially be of use on groups which value membership status or message source in considering/weighing/rewarding content contribution.

Cheers,
Christos

PS: As a matter of fact, I would argue that we should take this and apply it further to the rest of the user badges, set special colors for them, or at least the most important ones; research has shown that old-school round steam gauges have one superiority to digital readout displays because, after you have familiarized yourself with the gauge layout and settings/values/"badges", it only takes a quick glance (or peripheral vision) to know where the dial is hence what setting/value/"badge" it points to, you don't have to "read" the instrument, or oven look directly at it; but you have to literally look and read the digital number display.  Anyone here who flies will attest to that, PPL to ATP, doesn't matter.  For the non-pilot folks, a quick test comparison between an old school round clock and your microwave's clock will show you that effect; and if you keep the clock within your nearer peripheral vision field, like let's say right next to your monitor, you can be looking a the monitor typing or whatnot, and still get a very good idea of the time without looking at the clock.  You can't do that with a digital number clock, you have to look at it and read it.

Similarly, right now in the sea of light blue, reading is your only lifejacket; but with different badge colors, after we memorize them, a quick glimpse/glance can warns us, plus tell us what's going on; one side benefit would be that if one had the whole member list onscreen, a scrolling sweep or two would give you a good idea of the [badge/user setting] group distribution, kinda of a visual self-reporting tool. 

Maybe I should start a new topic and reference this one.



moderated A minor textual discrepency #bug

Malcolm Austen
 

When I initiate the joining process (with a dummy but valid) address, the resulting web page https://kent-eng.groups.io/g/all-Kent/joined says :
Look for a message from Groups.io with the Subject: "Confirm Your Groups.io Account"

However, the message received actually has the subject line:
[KEN] Confirm your join-ken-eng@... email address

Can these please agree with each other?

Malcolm.

-- 
Malcolm Austen <malcolm.austen@...>


moderated Re: Two issues in joining a group #bug

Malcolm Austen
 

As this seems to be opening a bigger can of worms than I had appreciated, lets stop this here and I'll raise the two items separately. My second point will reappear in [GMF] for some kicking around before it comes back to [beta].

Malcolm.

-- 
Malcolm Austen <malcolm.austen@...>

On 28/01/2021 22:04:01, Malcolm Austen <malcolm.austen@...> wrote:

First a minor bug in some text ... when I initiate the joining process (with a dummy but valid) address, the web page https://kent-eng.groups.io/g/all-Kent/joined says :
Look for a message from Groups.io with the Subject: "Confirm Your Groups.io Account"

However, the message received actually has the subject line:
[KEN] Confirm your join-ken-eng@... email address

Can these please agree with each other?

And then issue two which I'm sure has been discussed before ... the message sequence is all wrong. First I get a welcome message (and the owner is told I have joined the list) and then I get a second email asking me to confirm my request to join the list. (In reality I think these three messages are all sent at the same time and the exact arrival order is unpredictable.) The welcome message should and must not go out until the confirmation process has completed. It's not right for the member to still be in [NC] status when both they and the owner have been informed they have joined the list.

I am happy that the owner should be informed of the application but I feel strongly that the sequence should be:
1. user applies to join
2. user is asked to confirm and owner is informed of the application, user set [NC]
If (and only if) user does confirm then
3. [NC] is removed, user is sent welcome message and owner is informed  of completion

Keep safe, Malcolm.

-- 
Malcolm Austen <malcolm.austen@...>

2101 - 2120 of 30101