Date   

moderated Re: Out sick

Sarah k Alawami
 

Oh man feel better. Rest up and be blessed.

Take care all.


On Mar 27, 2018, at 8:28 PM, Mark Fletcher <markf@corp.groups.io> wrote:

Hi all,

I have come down with the flu. Expect support response times to suffer the next few days, unfortunately.

Thanks,
Mark


moderated Re: Out sick

Douglas Swearingen <dougiebehr@...>
 

Mark,


Do not worry about the support response times suffering.  You need to get yourself well.


Take care of yourself and do not let this turn into Pneumonia or some other such worse condition.


Doug




From: main@beta.groups.io <main@beta.groups.io> on behalf of Mark Fletcher <markf@corp.groups.io>
Sent: Tuesday, March 27, 2018 9:28 PM
To: main@beta.groups.io
Subject: [beta] Out sick
 
Hi all,

I have come down with the flu. Expect support response times to suffer the next few days, unfortunately.

Thanks,
Mark


moderated Out sick

 

Hi all,

I have come down with the flu. Expect support response times to suffer the next few days, unfortunately.

Thanks,
Mark


moderated Re: #featurerequest Message Numbering in Messages View (Number/Total Messages) #suggestion

Gerald Boutin <groupsio@...>
 

Bob,

I am admittedly a bit stuck in my ways. I am suggesting that knowing this info while in messages view would be helpful. I usually read posts on my desktop with HD monitor, so it isn't awful. However, I would imagine having to bounce back and forth would be even more painful on a phone or small tablet.

So how do you keep track of which posts you've read or haven't read? Being primarily in messages view, for me each message shows as read or unread in the browser. When I leave off and come back later, I can start again looking at unread messages. I do find it useful keeping track of who said what.

--
Gerald


On Tue, Mar 27, 2018 at 03:47 pm, Bob Bellizzi wrote:
Gerald,
I switch back and forth between Messages display and Topics display.
I first start reading the most recent postings.  If I'm interested in the thread, I switch to the Topics view and open it which puts me at the beginning of the thread with all messages in that thread opened.
I can then scroll down the thread reading, skipping as needed to get through the complete list..

--

Bob Bellizzi

Founder, Fuchs Friends ®
Founder & Executive Director, The Corneal Dystrophy Foundation


moderated Re: #featurerequest Message Numbering in Messages View (Number/Total Messages) #suggestion

Bob Bellizzi
 

Gerald,
I switch back and forth between Messages display and Topics display.
I first start reading the most recent postings.  If I'm interested in the thread, I switch to the Topics view and open it which puts me at the beginning of the thread with all messages in that thread opened.
I can then scroll down the thread reading, skipping as needed to get through the complete list..

--

Bob Bellizzi

Founder, Fuchs Friends ®
Founder & Executive Director, The Corneal Dystrophy Foundation


moderated Re: New search is live

Benoît Dumeaux
 

Other idea option to search only in title of topics.


moderated Advanced Search (Filters) #suggestion

Duane
 

There have been some suggestions in other threads scattered around, so I thought having a dedicated topic might be worthwhile.  I think Shal has listed most of the items I'd like to see available, https://beta.groups.io/g/main/message/14955, but we might as well make the wish list complete.

Duane


moderated Re: automatic deletion, why?

Chris Jones
 

Judging from an auto - deletion that arrived this morning wowway.com should also be on the list.

Chris.


moderated Re: #suggestion Need List-Post header in group messages #suggestion

 

Hi Eric,

On Fri, Mar 23, 2018 at 3:18 PM, Eric Searcy <emsearcy@...> wrote:

I'm inclined to see this as a Thunderbird bug, but regardless, would a reasonable compromise be to add this List-Post header, for now, only for lists configured as "reply to sender"?  Or would that make matters more confusing?

I've added the List-Post header for messages sent to groups configured as reply-to-sender.

Thanks,
Mark 


moderated Icons

Sharon Villines
 

A video from Jakob Nielsen the web research firm on icons

Universal icons are rare. To help overcome the ambiguity that almost all icons face, a text label must be present alongside an icon to clarify its meaning.
http://bit.ly/2IUkxSu

Sharon
----
Sharon Villines
TakomaDC@Groups.io


moderated Re: Join flow - Pending Member Notice & Notice to group admins

 

I could go with "split the difference." That would be consistent and very clear.
 
--
J

 

Messages are the sole opinion of the author, especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


moderated #featurerequest Message Numbering in Messages View (Number/Total Messages) #suggestion

Gerald Boutin <groupsio@...>
 

I am used to viewing posts online from oldest unread to newest in Messages view. I would find it useful to know how many messages are in the topic of the message I am looking at and the message number in the topic before I start replying.

For example, this post would show up as "Message Numbering in Messages View (Number/Total Messages) (1/1)" since it is the first post with one message in the thread. If this was (1/10), I would know that I better continue reading through the thread before I bothered to offer my two cents worth of advice.

--
Gerald


moderated Join flow - Pending Member Notice & Notice to group admins

Shal Farley
 

Hi,

I'm changing the Subject of this reply because we've drifted (I should have done this on my prior reply). I'm replying to beta #16473:
Re: [beta] Site updates #changelog
https://beta.groups.io/g/main/message/16473

J,

This means that with email requests, until the person confirms,
moderators have no clue that anyone has applied to their group: ...
I concur that it would be better if there were at least an activity log entry to show the receipt of the +Subscribe command. This is useful when trying to help would-be members that are having trouble. If there is an entry you can tell them to look in their Spam folder for the confirmation request. If there's no entry you can tell them that they didn't send the command, or didn't send it to the right address.

Also: if an email addresses can be spoofed, so can a false email
address (or somebody else's email address) be entered in a web request
(case 2). ... So shouldn't case 2 be handled just like the email-
request cases - namely, CE sent and returned before sending PS and
logging/adding pending member ...
Logically perhaps it should. But that might not give the best user experience. I think this "shortcut" for web users is part of keeping the Request/Join flow as simple as practical from the point of view of the would-be member (if not the group admins). The web user in case 2 is put into a quasi-logged in state wherein they can set their subscription options, and possibly account options, but can't actually participate in any groups. A red note at the top of every page reminds them that they need to confirm their email before they can participate.

I think Yahoo Groups ruled out case 2 by forcing a sign-in during the Request/Join session; in other words converting it to case 4. But that sidetracking (now go create an account then come back) was the source of an immense amount of user confusion and never-completed Request/Join attempts. A complexity Groups.io does well to avoid.

The key thing adding them to the group in this NC state does is give the group admins a "handle" on them, so that they can send messages and ad-hoc confirmation requests to help the would-be member become an actual member. That's a lot better than a mere activity log entry (and vastly better than no information at all).

Or alternatively, do them at once for for email requests, as well?
The only reason against it I can think of is a fear that the group might be more readily flooded with invalid +Subscribe emails than by Web access.

Also there's a good reason not to send a Pending notice to an unconfirmed address - whether web or email originated: an unscrupulous group owner could use it as a mechanism to spam arbitrary addresses, leveraging the authentication and good reputation of Groups.io's outbound servers to get their junk past spam filters.

So maybe split the difference. NC membership immediately for both web and email (cases 2 & 3), but Pending notice deferred until confirmation for both cases.

Related to all of this, as I've questioned before and as you bring up
here: why be so careful and assume that the email address has been
spoofed and send the CE at all in case 5?
Because without some way of knowing that the +Subscribe command actually came from the owner of that address (i.e. that it wasn't "spoofed") people could be fraudulently subscribed to groups they never intended to join. Either by action of spambots (as happened frequently in antediluvian days of classic Yahoo Groups) or by malcontents or pranksters. A response to a confirmation request email is a pretty solid way of knowing for sure.

But as I mentioned last time, perhaps there are more modern techniques that could be used, in the majority of cases, to take that extra step out of the procedure.

Shal


moderated make "BCC me" the default in private replies, or at least in threads with private hashtags #suggestion

 

I just posted in a thread in another group besides mine and realized later that my reply didn't post onlist. I tried to post again and saw, the second time, that the thread had been marked "private," evidently due to a hashtag. So the second time, I BCC'd myself. Meanwhile I received offlist emails from a third member (someone besides the OP) trying to explain to me that unbeknownst to her as well, the thread had gone private, and that she didn't want me to think that she wasn't replying to ME: it was just, as she realized after the fact, that the thread had gone private.

I think that to solve this kind of miscommunication, where a thread is marked private but nobody realizes it until after several posts, resulting in people to whom their reply was intended not reaching the person if that person is not the OP, etc. etc. etc., that "BCC me" should be the default, either in all private replies onlist or just in all threads marked with a private hashtag.
--
J

 

Messages are the sole opinion of the author, especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


moderated Re: Site updates #changelog

 

Shal,

My primary concern is with restricted groups, and with an inconsistency in the sequence of the confirm vs. send-pending-notice processes in a restricted group. Much of this I've already described in the thread I originally started about this:
https://beta.groups.io/g/main/topic/order_of_sending_welcome/14827755
.
For my own ease of recall during the discussion, I'll summarize your cases in one easy place :)
1. web request, existing account, logged in
2. web request, non-account 
3. email request, non-account 
4. web request, existing account, not logged in
5. email request, existing account 

I'm assuming a restricted group, although a separate, comparable discussion about unrestricted groups might also be helpful.

In case 2, as Mark as described (and as I have confirmed via testing), the confirmation email (let's call it CE) and the Pending Subscription notice (PS) are sent at the same time. This may, as you've acknowledged below, result in an NC pending member in the members list. But in cases 3 and 5 (all email requests), no PS is sent until after the CE has been sent and returned by the requestor (as Mark has also described, and as I have confirmed via testing).

This means that with email requests, until the person confirms, moderators have no clue that anyone has applied to their group: no pending member appears, no notification, etc. I feel like I am repeating myself, but this is the problem I'm bringing up - not whether or not the confirmation is necessary, as you (Shal) are referring to.

Also: if an email addresses can be spoofed, so can a false email address (or somebody else's email address) be entered in a web request (case 2). (Cases 1 and 4 don't matter, because the person is either already logged in, or is required to log in after making the request, respectively.) So shouldn't case 2 be handled just like the email-request cases - namely, CE sent and returned before sending PS and logging/adding pending member (perhaps it is, but I don't think Mark has clarified this yet)? Or alternatively, do them at once for for email requests, as well? In other words: if confirmation is important before sending the PS in the case of email requests and possible spoofing, it seems no less important in a web request from a non-account. So why hold the PS until after confirmation in one case but not the other?

Related to all of this, as I've questioned before and as you bring up here: why be so careful and assume that the email address has been spoofed and send the CE at all in case 5? Here I don't know enough about how spoofing works to comment. But as for whether or not the concern about spoofing and requirement for confirmation in case 5 is new or old, I am pretty sure that even if it's not new in the sense of "recent," I remember conversations wherein the fact that "confirm" was strictly requestors without a groups.io account was explicitly referred to and/or assumed. I don't remember who said it or when, and whether they were right or wrong, but it used to be a generally acknowledged fact/myth. No matter at this point; it's water under the bridge.:)

--
J

 

Messages are the sole opinion of the author, especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


moderated Re: Site updates #changelog

 

J,

It seems to me that "confirm" has changed in some subtle (and some not
so subtle?) ways recently. ... Yet now, ... people are also required
to confirm that they want to join the particular group, even if they
already have an account.
I don't think that's new.

I hate to belabor this, but that results in inconsistent information
to moderators in the two cases.
I think there are five cases.

The easy one first:

1) A logged-in user clicks the Request button (restricted group) or Join button (unrestricted).

In this case no confirmation is needed - the identity of the user has been authenticated by the login, the desire to join the group proven by the button click.

The other extreme are the two cases of an unknown email address:

2) A web user clicks Request or Join, and enters an email address which does not yet have an account at Groups.io
3) A +Subscribe request is received from an address which does not yet have an account at Groups.io

In both these cases it is necessary to confirm that the owner of that email address is the person who took the action. A response to the email confirmation request serves also to confirm the address in its new account.

Absent a response to the confirmation request I think case 2 results in an NC member, but case 3 results in an abandoned +Subscribe request.

And the two cases of a confirmed email address:

4) A web user clicks Request or Join, and enters an email address which does have an account at Groups.io

The site recognizes the address, and prompts the user to log in. Doing so effectively converts this to case 1, no further confirmation needed. I'm not entirely sure what happens if the user doesn't log in, but I think it should abandon the Request or Join action because the user is unidentified (could be anyone typing that address).

5) A +Subscribe request is received from an address which does have an account at Groups.io

In this case it is still necessary to confirm that the owner of that email address is the person who took the action, because email From addresses can be spoofed. A response to the email confirmation request completes the +Subscribe action, resulting in either a Pending or Joined member.

Absent a response to the confirmation request I think this case again results in an abandoned +Subscribe request.

In case 5 specifically, but probably also case 3, I think it would be practical to skip the confirmation request if the email command arrives with sufficient authentication.

I think that may require two things:
a) that the email can be authenticated to have come from the domain claimed in the header From address; and
b) that domain be "known" by Groups.io to disallow arbitrary spoofing. Gmail and Yahoo Mail, as examples, require a user to demonstrate control over an address (ability to receive a verification email) before allowing an account to create outgoing messages from that address. Thus I could not, without your cooperation, use my Gmail account to forge a message from your Gmail account, even though I can use it to forge messages from accounts that I own.

Shal


moderated Re: Google Drive Integration

Bruce Bowman
 

The only capability of the Google Drive integration at this time is to save email attachments there.

However, see this thread: https://groups.io/g/GroupManagersForum/message/6072

Bruce


moderated Re: Site updates #changelog

 

On Sat, Mar 24, 2018 at 04:48 pm, Shal Farley wrote:
* NEW: For restricted premium/enterprise groups, approving a Not
Confirmed pending member now automatically confirms that account
as well.
Um, wasn't this already true?
I thought it was, unless it was my imagination.

It seems to me that "confirm" has changed in some subtle (and some not so subtle?) ways recently. It would be good to get a complete clarification. For example, I'm nearly certain that confirmation was formerly only required of someone applying to a group who had no groups.io account previously. Yet now, as you (Shal) recently explained, people are also required to confirm that they want to join the particular group, even if they already have an account. That may make more sense, but it seems to me like it was a change. Was it, or am I imagining things?

Also, in connection with the approval process as discussed in another thread: when someone applies to a group via the web they are sent the group's Pending Subscription notice (if any) at the same time as they are sent the confirmation email. This means that they can (and often are) approved before they confirm, resulting in NC (although not any longer for Premium groups). Yet when applying via email, they are first sent the confirmation email and required to confirm, and THEN sent the pending notice. I hate to belabor this, but that results in inconsistent information to moderators in the two cases. 
 
--
J

 

Messages are the sole opinion of the author, especially the fishy ones.

I wish I could shut up, but I can't, and I won't. - Desmond Tutu


moderated Re: Site updates #changelog

 

Mark,

* NEW: For restricted premium/enterprise groups, approving a Not
Confirmed pending member now automatically confirms that account
as well.
Um, wasn't this already true?

" * NEW: For premium/enterprise groups, when approving a pending
subscriber who is also not confirmed, we confirm the member."
https://beta.groups.io/g/main/message/14767

Shal


moderated Re: There should be a #wiki button to create a _Sidebar page #suggestion

 

Mark,

I've changed it so that the buttons are always there, just disabled if
you have a Sidebar and/or Footer.
Excellent. I generally prefer that behavior, at least for things I can control.

How about changing them to Edit Footer or Edit Sidebar, respectively, instead of disabled?

Shal