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@gmail.com> 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@gmail.com>, 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@gmail.com 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

Shal:

Understood now.

So if no aliases are defined and I send an email to <myname+sometext@gmail.com>, 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@gmail.com and process it as a valid address.

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

Peter

Bruce,

I like the idea, if ... given only to Owners and Moderators with the
"edit archives" permission.

Yes, I believe that was the intent, similar to Locking or Moderating a topic.

The ability to hide individual messages can create confusion when the
remaining messages cannot be properly assessed in context.

True, but the use case I see for hiding just a single message would be in an otherwise valuable and/or important topic where just one or a few offending replies were made. Most likely, as in the OP's use case, the offending messages are destined to be deleted, but for whatever reasons need to be kept temporarily.

I leave it to the moderator to judge which is the better remedy (hiding the message(s) or the whole topic) based on their knowledge of the circumstances at hand.

Shal

Peter,

Shal's reference to gmail using "+" in some way associated with
aliases, is not consistent with the observation (by me and others)
that gmail truncates leftsides at a "+" . An email to
username+anytext@gmail.com is delivered to username@gmail.com and NOT
rejected back to the sender as "No such user".

That's exactly what Gmail means by an alias: username+foo is an alias for username. But it isn't stripped - the +foo part shows in the received message and is available for use in filter definitions (which is the intended use case).

The link Shal gave to a Gmail help page about aliases doesn't contain
any reference to the "+" character..

You need to open the expander titled "Filter using your Gmail alias".

Shal

On Wed, Sep 25, 2019 at 04:45 PM, Bryce Weathersby wrote:

I would like a feature to able to Hide Topics/Messages.

I like the idea, if restricted to Topics, and given only to Owners and Moderators with the "edit archives" permission.

The ability to hide individual messages can create confusion when the remaining messages cannot be properly assessed in context. Yes, I understand that subscribers can already delete their own messages, thus creating the same problem -- I just don't want to provide another tool by which history can be altered.

The message archive is not a personal timeline à la Facebook, and I would be disappointed to see it treated as such.

My $0.02,
Bruce

On Thu, Sep 26, 2019 at 09:23 AM, Dave Wade wrote:

I would however say that there may be a case for filing a GDPR failure against them

Which was the point I was making, albeit rather obliquely in my earlier post.

An email to the ICO (Information Commissioner for non - UK readers) might just stir things up a bit.

Chris.

In my last message message, something or someone downstream of me replaced the word "gmail" after the @ symbol, by three dots,in two places, and that wrecked the meaning. Truncation of the user-part at the + sign only occurs WITHIN the gmail domain, not in ANY domain!

Peter

Shal's reference to gmail using "+" in some way associated with aliases, is not consistent with the observation (by me and others) that gmail truncates leftsides at a "+" . An email to username+anytext@gmail.com is delivered to username@gmail.com and NOT rejected back to the sender as "No such user". The link Shal gave to a Gmail help page about aliases doesn't contain any reference to the "+" character..

Dave's reference to moderators "using this to chat to each other" is a reference to using the <groupname+owner@groups.io> address as a mini-group.

Peter