Date   

Re: Locked topic not locked #lock

 

Dave,

 
How did this happen? Just had someone post a reply to a message in a topic I locked a month ago. Both the OP and the reply-er are unmoderated and the post just appeared this morning.
 
Look in the Topics view of your group's Messages page to see the new message is actually in the locked topic, or started a new topic.
 
One of the weaknesses of locking (or moderating) topics is that it is so easy for a member to just create a new one by making a minor adjustment to the Subject text. Or by using the New Topic function in the group's web pages (even if they copy/paste the original Subject text).
 
Or, given that a month has elapsed, that is the time limit of the Subject matching algorithm when the received message does not contain either the In-Reply-To or References header field. Some email interfaces don't generate those fields even when the user chooses the Reply function.


Even if for some really strange reason the reply was sent before the topic was locked on August 22 and held up by some quirk of earthlink (the reply-er's email service) shouldn't it have been blocked by the lock on the topic?
 
Yes.
 
I don't think that's what happened.
 
Shal
 

--
Help: https://groups.io/static/help
More Help: https://groups.io/g/GroupManagersForum/wiki
Even More Help: Search button at the top of Messages list


Re: Locked topic not locked #lock

David Grimm
 

And not being familiar with hashtags, did I just goof up by putting the 'lock' hashtag on my original question, thereby locking THIS topic?

Dave


Locked topic not locked #lock

David Grimm
 

How did this happen? Just had someone post a reply to a message in a topic I locked a month ago. Both the OP and the reply-er are unmoderated and the post just appeared this morning. Even if for some really strange reason the reply was sent before the topic was locked on August 22 and held up by some quirk of earthlink (the reply-er's email service) shouldn't it have been blocked by the lock on the topic?

Dave


Re: Messages to +owner being wrongly routed to the whole group

 

Peter,


(either btinternet.com or synchronoss.net - we don't know which),

I think we do know that it is synchronoss.net. That's what the evidence says to me, GMF #18774.

Knowing which may help those trying to get it fixed at the source, but I don't think it makes any material change to your case for what Groups.io should do.

I would still prefer a solution that doesn't involve changing the command convention for everyone.

But I don't know what that would be. Among the examples I examined I think there were some that did not contain an original To field or other hint to what the original command might have been, so there may not be a reliable way for Groups.io to "patch around" the problem when messages are delivered through synchronoss.

I'm still of the opinion that affected members can triage their use of email commands (by using the webmail interface) and affected groups can triage members that don't by moderating them.

This question has not surfaced in the prior five years of Groups.io's operations. Which makes me wonder if it was always a problem, but unrecognized / unreported (in GMF), or if synchronoss recently broke something? Does anyone have a back history of this affecting their groups?

Shal

--
Help: https://groups.io/static/help
More Help: https://groups.io/g/GroupManagersForum/wiki
Even More Help: Search button at the top of Messages list


Adding a company name to the membership information

Seth Newberry
 

Hello GMF
We manage membership with a company membership agreement.  However, we often allow people to be added to a mailing list with their personal email.  The default membership admin screen shows Name, Email, Delivery and Join Date.   Is it possible to add a field for Company Name in the membership admin screen?

--
Seth Newberry
General Manager of Standards
Joint Development Foundation


Re: Messages to +owner being wrongly routed to the whole group

Peter Martinez <Peter.Martinez@...>
 

Jeremy:

Gmail certainly does ignore dots in the left-side of an email address, but ONLY on left-sides of email addresses arriving into the gmail domain. firstsecond@gmail,com is treated the same as first.second@gmail.com and indeed the same as first....sec.ond..@gmail.com. This is quite legal. If there was already a gmail user with the name firstsecond and someone else tried to join gmail with the name first.second they would be told there was already a user with that name and to choose something different.

I have discovered recently that first+anytext@gmail.com is treated as first@gmail.com so gmail are truncating left-sides at the + sign. This at first looks like the same bug that we are discussing here, but it isn't - this is gmail's own private interpretation of left-sides of emails inbound to ITS OWN domain, NOT truncation of left-sides which are en-route to OTHER domains - a practice which is outlawed by RFC2821.

This means that groups.io need not be frightened of dots in the left-sides of email addresses in their own domain which are to be interpeted in some clever way when they arrive at groups.io. The fact that dots on the left side are commonplace and seem to be handled correctly by all known en-route hosts, means that if groups.io changed the + to a dot, it would certainly be handled correctly.

The problem I have raised in this thread is that there seem to be en-route hosts that DO truncate left-sides at the first + character in EN-ROUTE EMAILS, we have spotted one such en-route host that does this (either btinternet.com or synchronoss.net - we don't know which), and I think there must surely be others we haven't seen yet, since these people all buy their hardware/software from the same places. OK, the correct solution is to fix the hosts that do it, but I would make a case for implementing ANY solution which eliminates the problem NOW.

Regards
Peter


Re: Gaining access to a Group via it's URL

Bob Gerard
 

On Sep 22, 2019, at 10:18 PM, Shal Farley <shals2nd@gmail.com> wrote:

In a way, it is because you have to start somewhere. That is, the very first time a person visits Groups.io's web pages they don't have a password, so there had to be a mechanism (such as all membership sites have) for "signing up" and creating an account and password. All such sites also need a mechanism to recover from a forgotten password.
<Big snip>

Thanks so much for that explanation, Shal. Very kind of you to take the time to write it.



Bob
———
“ A man sees in the world what he carries in his heart.”
— Goethe, Faust


Re: Messages to +owner being wrongly routed to the whole group

Jeremy Harrison
 

There is at least a potential issue with changing to a dot in I seem to remember that gmail ignores dots in the left side of email addresses (so group.owner and groupowner are regarded as the same) - but whether this at the sending end, or only at the receiving end (i.e. this only affects gmail addresses), I don't know.

Jeremy


Re: Groups.io Anniversary - Mon, 09/23/2019 #cal-notice

 

Congratulations, groups.io! And thanks to the moderators for your unceasing help and guidance and to Mark for the fantastic job he is doing!

Victoria


Groups.io Anniversary - Mon, 09/23/2019 #cal-notice

GroupManagersForum@groups.io Calendar <noreply@...>
 

Groups.io Anniversary

When:
Monday, 23 September 2019

Description:
Introducing Groups.io posted in Mark Fletcher's Blog on this date is 2014.


Groups.io site updates #changelog

 

Hi all,

This week's change log:
https://beta.groups.io/g/main/message/22249


Feel free to reply to this topic if you'd like to comment on the
changes. Or better yet, if you expect a lot of discussion start a new
topic (or rejoin an existing one) about a specific change.


BUGFIX: Fix issue where the photo may not match the thumbnail if the
album was sorted by Posted.
BUGFIX: In some cases, when doing a photos search, clicking an
individual photo would bring up a different photo.
I suspect these were consequences of the choice to use an album-relative index in the URL to photos, rather than an unchanging Permalink.


Comments about these are welcome:

API: Added sort_field, second_order, query, sort_dir fields to the
pagination object.
CHANGE: Sorting group calendar ICS feeds by start time, to maybe,
hopefully, fix a weird Outlook bug.
API: Added /registerdevice endpoint for registering device tokens for
notifications.
[API] NEW: Added exclude_aliases flag to /gethashtags endpoint.
API: Added /searcharchives endpoint and related search_result and
search_results_list objects.
API: Added profile_photo_url, name and can_view_profile fields to the
chat object.
API: Added alias field to hashtag.
API: Added announce flag to /newchat endpoint.
API: Setting the chat_sub field on the chat object whenever we can.
Previously this was only set in a few instances.
BUGFIX: You couldn't change the case of your email address; it thought
you were merging with a different email address and would fail.
API BUGFIX: The /postdraft endpoint was not setting Reply headers
correctly for replies.
API: Added /addalbum, /updatealbum, /deletealbum, /addphotos,
/updatephoto, /deletephoto endpoints.

Please call out any you find significant.

Shal


--
Help: https://groups.io/static/help
More Help: https://groups.io/g/GroupManagersForum/wiki
Even More Help: Search button at the top of Messages list


Re: Gaining access to a Group via it's URL

 

Bob,

BTW - in the Wiki page, I was surprised to see that no password was
required.
In a way, it is because you have to start somewhere. That is, the very first time a person visits Groups.io's web pages they don't have a password, so there had to be a mechanism (such as all membership sites have) for "signing up" and creating an account and password. All such sites also need a mechanism to recover from a forgotten password.

The innovation at Groups.io was the realization that there's no reason that mechanism (email a special link) needed to be an exceptional thing that happens only at first sign-up, or after a forgotten password. So Groups.io's Log In page has also the "Email me a link to log in" button which you can use anytime, and even rely solely on that mechanism without ever creating a password. It does the same thing as the "Forgot your password, or don't have one yet?" link, but doesn't imply that you're about to set a password.

Eschewing the use of a password shifts your vulnerabilities slightly.

On the one hand, not having a Groups.io password means that no one can guess it or steal it in order to take over your account. Instead they have to compromise your email service - which hopefully is something you would pay closer attention to keeping secure. And if someone does compromise your email service, having a Groups.io password wouldn't keep your account any more secure - that person could use the password reset mechanism to take it over anyway.

On the other hand, not having a Groups.io password means that if you lose access to your email address you lose the ability to log in to Groups.io. You then have a limited opportunity to change your email address while your browser is still logged in to Groups.io - if you were already. If you routinely log out, or delete cookies from your browser, you may end up locked out of your Groups.io account. A smaller problem, generally, than unexpectedly losing your email account, but a problem nonetheless.

Shal


--
Help: https://groups.io/static/help
More Help: https://groups.io/g/GroupManagersForum/wiki
Even More Help: Search button at the top of Messages list


Re: Messages to +owner being wrongly routed to the whole group

 

Bruce,

-- With the hyphen usurped for another purpose, the plus (+) sign was
implemented for +owner messages

Is that pretty close, or did I dream all that?
I don't know if it was planned that way in Mark's mind, but the choice of + for email commands was in place at Groups.io's launch, predating my suggestion of subgroups and their subsequent implementation.
https://beta.groups.io/g/main/topic/3379

I thought there had been some discussion on the + versus - for email commands. That is, I thought Mark explained his choice at one point, however my search efforts aren't finding that now.

Shal


--
Help: https://groups.io/static/help
More Help: https://groups.io/g/GroupManagersForum/wiki
Even More Help: Search button at the top of Messages list


Re: Problem with muting topics

 

Marina,

She says that, although she follows the link in the footer of the
e-mail and then successfully (at least that's what the system tells
her) completes the process online, she keeps receiving the unwanted
topic.
...
In my group I have to merge messages fairly often as the system fails
to recognize some replies ... as belonging to the same topic and just
leaves them floating about. It has always been a problem.
As you suspect, this might be related in that messages won't be muted if they aren't recognized as being part of the muted topic. That you later merge them won't help, at least not for members receiving individual message emails.

(with tags like Ris:, R:, etc)
The system attempts to ignore typical prefixes like "Re:" when comparing Subject texts to determine whether an incoming message should be treated as part of an existing topic. Catching all of the various language variations in those prefixes has been an on-going effort. You can help that out by reporting such cases to support@groups.io. That is specifically for cases where you have good reason to believe that the message should have been part of an existing topic - as when it includes a quote from a message in the topic or has a Reply-To or References header field that names a message in the topic.

It does not explain why my member started having problems with this
feature in July, though.
I don't have an answer for that either.

It is possible that an update to the subject matching algorithm caused messages to drop out which would not have previously, it may also be that something has changed about the way some of your group members create replies.

Shal


--
Help: https://groups.io/static/help
More Help: https://groups.io/g/GroupManagersForum/wiki
Even More Help: Search button at the top of Messages list


Problem with muting topics

Marina
 

Dear all,
a member of my group contacted me complaining about a problem with the Mute this Topic feature.
She says that, although she follows the link in the footer of the e-mail and then successfully (at least that's what the system tells her) completes the process online, she keeps receiving the unwanted topic.
This has been going on since July. Before, apparently, the feature worked fine.

How can I help her? I can't figure out what could be the problem.

In my group I have to merge messages fairly often as the system fails to recognize some replies (with tags like Ris:, R:, etc) as belonging to the same topic and just leaves them floating about. It has always been a problem.
I wonder if this may have something to do with the Mute this Topic problem. It does not explain why my member started having problems with this feature in July, though.

Thank you in advance for your help,
Marina


Re: Facebook integration URL not accepted #integration

Duane
 

On Sun, Sep 22, 2019 at 01:27 AM, <player2@...> wrote:
Does the URL have to have a certain format perhaps?
Unfortunately for those that use them, FB integrations aren't working due to a change they've made:
https://beta.groups.io/g/main/message/22150

Duane
 --
Help: https://groups.io/static/help
GMF's Wiki: https://groups.io/g/GroupManagersForum/wiki
Search button at the top of Messages list
A few site FAQs: https://groups.io/static/pricing#frequently-asked-questions


Facebook integration URL not accepted #integration

Sam Pierce
 

Hi all:

When I enter the URL of my Facebook page, I get the following error:

That name does not appear to be the name of a Facebook Page.

Now I've seen a handful of threads addressing this previously, but I can confirm that my page is public to all. It's visible in an incognito browser window. It has no age or country restrictions.

Does the URL have to have a certain format perhaps?


Re: How to allow editing but not deleting

Chris Jones
 

On Sat, Sep 21, 2019 at 06:44 PM, Stef Hambrook wrote:
I'm not sure I trust everyone with the DELETE part of the menu that pops up under the word MORE. 
To the best of my knowledge your stuck with it; while Editing by a subsciber can be inhibited Deleting a post cannot. If there is a means of stopping people deleting their posts I have yet to find it.

It is worth rembering that getting to the Delete tab requires clicking on More. Having clicked on Delete then that action has to be confirmed (or cancelled) by clicking on yet another tab, meaning that it requires 3 clicks to delete a message. Individual Subscribers can only delete their own posts, nobody else's; that privilege is for Owners & Moderators only.

IMHO you are worrying unnecessarily, unless your Subscribers really are clumsy, and even then I suspect that clumsiness on its own will not be enough.

Chris


Re: How to allow editing but not deleting

Stef Hambrook
 

Ok.  I'm starting a forum for a band and I'm not sure I trust everyone with the DELETE part of the menu that pops up under the word MORE. 
Fingers on smartphones are cLuMsY...


Re: How to allow editing but not deleting

Bruce Bowman
 

On Sat, Sep 21, 2019 at 08:28 AM, Stef Hambrook wrote:
When you set the privileges for moderators or members how can you allow editing but not deleting?
Stef -- There is [currently] no provision within groups.io that would allow one and not the other.

Regards,
Bruce 
--
The system Help is your friend.  https://groups.io/static/help

18361 - 18380 of 37151