On Oct 1, 2019, at 1:21 PM, Mark Fletcher <markf@corp.groups.io> wrote:

In the new system, should these checkboxes exist? That is, should the person adding the file/creating the event/starting the chat/etc continue to have the option to not notify the group? And if they should continue to have that option, should it be extended to all new notifications?

Absolutely. Yes. Yes, and Yes.

I don't believe that Facebook lets you opt-out of sending notifications; at least I don't recall seeing such an option when posting photos/etc.

All notifications should be controllable, both to send and receive.

As to group notifications triggered by a member's action, these should also be able to be moderated; and which Moderators can moderate which notifications should be separate Moderator Permissions.

Duane . . .

On Tue, 01 Oct 2019 11:21:26 -0700, "Duane" <txpigeon@...>
wrote:

I believe they should exist (for all items) if turning them off isn't going to be a group setting, with a default of off. I'd also like to see it set so that someone can't send multiple notifications (of the same type?) within a short time if they can't be turned off.

I like this idea, not sending multiple notifications within a short
period of time. We won't all agree on the time frame, but if the check
box only appears after that time x minutes frame is over, we can
simply uncheck it again and we'll be good for another x minutes. This
might be useful when building a set of files, etc., in the files
section after the group is up and running.

Chances are by the time the members see the first notice, the files
will already all be uploaded in many cases. And, we would have the
option of unchecking the notification box, uploading the files, then
making a personal announcement about them only after we're finished.

Another alternative to this might be something in our personal
settings for the group. We could toggle it off to do multiple uploads
then toggle it back on either for the last one we do or leave it off
and just manually notify the members of uploads.

Donald




----------------------------------------------------


Join the Icom group, a general Icom (amateur radio) discussion
group on Groups.io:
https://groups.io/g/ICOM (recently launched, growing slowly)
**also, a new self-help group dedicated to your cat's health:
https://groups.io/g/CatVet (just launched)

On Tue, Oct 1, 2019 at 01:52 PM, Gerald Boutin wrote:

I realize that one might need options for receiving notifications as well as for initiating them

I just assumed that was going to be the case, and I think Mark said so explicitly at one point. I'd have to find the thread. Options to receive or not was part of the whole point....
 
--
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

Trying to get an integration going from one of the YAHOO groups just for the email list aspect. I dded the integration
email addres to the group member list, so the emails coming in to the groups.io system come in ok from the other
group, but for purposes of allowing the people on the groups.io system to reply and have it post, whats the best way?

I am a moderator of the YAHOO group so its easy to add in new emails to the system. I also can maybe use my email address
I am subscribed with as a way to make a filter or a forward, but not sure about the best way to do it.

On Tue, Oct 1, 2019 at 05:50 PM, Gerald Boutin wrote:

On Tue, Oct 1, 2019 at 03:21 PM, Duane wrote:

(A recent reason for this is the Upload Directory where a notification is sent for each file uploaded.  In a test, that resulted in over 100 notifications!)

Yes, and it also filled up almost 10 pages of notification messages online. Bad enough having to delete them from email accounts and online I would have to delete them one by one.

--
Gerald

Now that I think about this, I realize that one might need options for receiving notifications as well as for initiating them.
 
--
Gerald

On Tue, Oct 1, 2019 at 03:21 PM, Duane wrote:

(A recent reason for this is the Upload Directory where a notification is sent for each file uploaded.  In a test, that resulted in over 100 notifications!)

Yes, and it also filled up almost 10 pages of notification messages online. Bad enough having to delete them from email accounts and online I would have to delete them one by one.

--
Gerald

On Tue, Oct 1, 2019 at 12:21 PM, Mark Fletcher wrote:

Right now, some existing notifications are optional. When adding a file, for example, you have a checkbox to notify the group. Same with creating a calendar event, a new chat, etc.

 

In the new system, should these checkboxes exist?

I believe they should exist (for all items) if turning them off isn't going to be a group setting, with a default of off.  I'd also like to see it set so that someone can't send multiple notifications (of the same type?) within a short time if they can't be turned off.  (A recent reason for this is the Upload Directory where a notification is sent for each file uploaded.  In a test, that resulted in over 100 notifications!)

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

--

Changes to the site this week (resend with proper formatting):

• NEW: Upload Folder button in the Files area to upload a directory of files.
• API: Added /newmembernotice, /updatemembernotice, /deletemembernotice, and /getmembernotices endpoints.
• NEW: Checkbox to notify the group when you modify a file.
• CHANGE: Rate limit how often someone can report a message, to make abuse more difficult.
• CHANGE: Changed how we present start/end dates/times in calendar invite emails, to match how we present them when clicking Download Event. Even though both should be equivalent, apparently Outlook likes the Download Event version better.
• API: Added /searchfiles endpoint.
• BUGFIX: We now consider email addresses with parentheses as invalid.
• API: Added /searchphotos endpoint.
• API: Added /getdirectory and /getfile endpoints.
• API: Changed snippet field to summary in the search_result object for naming consistency.
• INTERNAL: Upgraded Go compiler to 1.13.1
• API: Added /testnotification endpoint.
• API: Handle case where group is not in the same domain as the API request. Caused incorrect direct add emails.

Have a good weekend everyone.

Mark

Bruce,

So who gets to see the hidden material? ... but do we include the
subscriber who posted it, too? Is that person still allowed to delete
or edit the message?

My initial concept was "no", matching Bryce's use case.

On the other hand I generally support the notion that a member should have the right to remove their own material. I'm willing to consider modifying my stance to say that a message, while hidden, is effectively removed (to other group members it would seem as if someone deleted the topic or message), and group owners always have the right to remove content from their group. So it may be acceptable for an owner to "lock down" a message in this manner.

But it seems to me that he at least needs to receive some kind of
notification that his post has been hidden. Otherwise we're going to
get a lot of inquiries to support/GMF to the effect that people's
messages are disappearing.

Mods/owners can already delete member's content, and no notice is sent. So I don't think hiding would produce a larger support problem. Most likely the group owners themselves would be the first one's asked. I'm not sure if there are other use cases than Bryce's, but I'd almost expect hiding to be a less often used feature than deleting.

Now the question of unhiding a message might be a case requiring notice to the original poster, in case he/she wants to delete the message after all. That could be handled like an owner/mod editing a message (when they choose not to resend to the group).

In the case of hiding an entire topic, I still (or especially) say "no" to showing the hidden message(s) to their respective posters. That way I think just leads to confusion. Likewise, in this case I wouldn't send any notices when the topic is unhidden. From the members' point of view hiding is the same as deletion - until it gets unhidden anyway.

Shal

--

Bruce,

Question: How does one find a hidden topic (or message) in order to
unhide it later?

In my concept they remain visible to mods and owners.

How are they flagged so those with the proper privileges to see it
know that other cannot (new status badge)?

Like a locked or moderated topic, I proposed an eye-slash icon (badge) to the left of the subject text.
https://beta.groups.io/g/main/message/22337

Like those other two, this would be an independent attribute that can be applied alone or in conjunction with the others.

Oh, interesting. The other two only stack up in search results. E.g.:
https://beta.groups.io/g/main/search?ev=false&q=%22Thread+view%22&ct=1
In other views locked seems to take precedence over moderated.

I would want hidden to stack next to the other icon(s) if any, it shouldn't take precedence over either, nor should either take precedence over hidden.

If a "Hide Message" function were (also) implemented there's a small question of where to put the icon when looking at a topic containing that message (as the Subject text is only shown at the top of the topic page). I think it should still be at the top, so somewhere among the Posting member identification on the left and the date & message number on the right.

Shal

On Thu, Sep 26, 2019 at 08:01 PM, Bruce Bowman wrote:

Question: How does one find a hidden topic (or message) in order to unhide it later?

That was brain fart on my part...Shal already suggested the eyeball-slash character as a label.

I still like the idea, but I guess I'm confusing myself with the use cases. This proposal is being pitched as the same as moderating or locking a topic, but it's not:
-- We're talking about being able to hide individual messages, which introduces a whole new level of granularity, and
-- The hidden material must remain visible to somebody, or we'll never be able to unhide it.

So who gets to see the hidden material? We already mentioned Owners and Moderators with the "edit archives" privilege, but do we include the subscriber who posted it, too? Is that person still allowed to delete or edit the message? Or is this yet another thing that needs to be set at the time of hiding?

Assuming we don't let the original post-er see it, then he won't be able to delete/edit it. But it seems to me that he at least needs to receive some kind of notification that his post has been hidden. Otherwise we're going to get a lot of inquiries to support/GMF to the effect that people's messages are disappearing.

Same goes for topics. Does a notification go to everyone who contributed to that topic? Or are we willing to just let topics mysteriously disappear without explanation?

These are some of the things I'm struggling with, and I don't think I've exhausted all the permutations yet.

Regards,
Bruce

On Wed, Sep 25, 2019 at 10:28 PM, Shal Farley wrote:

Instead I think that Hide Topic (and possibly Hide Message) should be a standalone item in the More menu, equal to the existing Moderate Topic and Lock Topic items. I think that is clearer, and makes it easy to Unhide the topic later, just as one may Unmoderate or Unlock it.

Okay, upon further reflection I can go along with that.

Question: How does one find a hidden topic (or message) in order to unhide it later? How are they flagged so those with the proper privileges to see it know that other cannot (new status badge)?

Bruce

On 25 Sep 2019 at 16:56, Mark Fletcher wrote:

On Mon, Sep 23, 2019 at 3:28 PM Glenn Glazer <glenn.glazer@...> wrote:

When we upload a file, there is a checkbox for notifying the list. There
is not one on the update window. Would it be possible to add this checkbox
and accompanying notification so that I can let members know when I've updated
our files?

I have added this.

Cheers,
Mark

Excellent! Thanks Mark.

Jim Fisher

--
http://jimellame.tumblr.com - My thoughts on freedom (needs updating)
http://jimella.wordpress.com - political snippets, especially economic policy
http://jimella.livejournal.com - misc. snippets, some political, some not
Forget Google! I search with https://duckduckgo.com which doesn't spy on you

Peter,

So if no aliases are defined and I send an email to
<myname+sometext@...>, it will simply strip and discard
"+sometext" (which is what I have seen), whereas if I define an alias
as "myname+other", it will recognise an incoming email to
<myname+other@... and process it as a valid address.

Both cases are received by the same user account at gmail, whether an alias was predefined or not. The alias case simply allows the user to filter incoming messages based on the alias.

So I can indeed cite this when I talk to BT as a feature which the
synchronoss/BT bug will break.

Hopefully it will help you persuade them.

Shal