Date   

moderated Re: Guidelines available to non-members via the help address even if GG are private #bug #fixed

Mark Irving
 

Preferably both. The private guidelines should be refused to anyone who tries the GROUP+guidelines@... address and is not a member, even when this address is not advertised in the automated help message.

  - Mark (not that Mark, a lesser Mark).


moderated Guidelines available to non-members via the help address even if GG are private #bug #fixed

 

Setup: group with private Group Guidelines.
Situation: Non-member sends message to the help address, gets back instructions that include sending email to group+guidelines address. Non-member sends email to that address and receives a copy of the group guidelines via email, which they should not be privy to.
Best solution IMO: the automated help message does not include instructions for getting the guidelines if the person is a non-member and the guidelines are private.
Alternate solution: keep help message the same but if a non-member sends a message to the guidelines address send back an error message ("this group's guidelines are only available to group members" yada yada).
--
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: #bug Gio iCal feed errors making GCal mad #bug #fixed

 

Hello,

On Fri, Mar 20, 2020 at 6:01 PM Dave Huseby <dhuseby@...> wrote:

The Hyperledger community uses Groups.io for all of our mailing lists and community managed calendars. We like to use the .ics feeds from groups.io to populate a GCal plugin on our Confluence wiki. We're finding that GCal fails to render all of the events in the feed. I ran our iCal feed through an ics validator and found tons of errors:


The issue was with a duplicate 'RRULE:' for events that repeated yearly. I've fixed it and that ICS file is now readable in GCal.

Thanks,
Mark 


moderated Re: Solving the overload issue (Selecting specific messages into two batches - Individual email vs. Full featured digest delivery) #suggestion

 

Homayon,

My responses below should not be taken as a disagreement with your suggestion, rather they are advice on what you can do with the system today. There are multiple approaches, but discussion of existing features is really off topic for beta, so I invite you to ask in GMF if you want more detail.
https://groups.io/g/GroupManagersForum

Unfortunately again and again members leave because they feel flooded
by a part of those mails containing rather little information - while
other msg's are very valuable
This has been an issue in one of my groups, GMF, as well. My general recommendation is that members feeling flooded should check out the Advanced Preferences section of their Subscription page on the group.
https://groups.io/g/GroupManagersForum/wiki/Help-Mock-up#Advanced-Preferences

So are group is loosing many members, they feel flooded with useless
mails. That shouldn't be.
I've added advice about the use of Advanced Preferences to GMF's Goodbye member notice, inviting them to rejoin if they wish, or simply monitor the group's messages on the web without joining (GMF has public messages).

1. The messages which contain "important medical information" which
should then be delivered instantly to all members and...
I agree with the moderator that using Special Notices seems like a good fit for this use case.

Another would be the use of a subgroup, with the primary group reserved for important moderator posts only (Announcement-Only Group). But that is a Premium feature so may not work for you.

Now you could say those members should choose themselves, if they want
a full featured digest or individual email delivery, but try to
explain that to some 460 mailing list dummies ...
You can use the Default Sub Settings tab in your group's Settings page to make the default subscription Email Delivery be digest or daily summary. That won't change any existing members, but new members would start out the setting you choose. You could also choose for them a Message Selection option other than "All Messages".

Shal


moderated Main subgroup screen sort columns, sort by sub-group #suggestion

Roland Roberts
 

I'm still new to groups.io and getting up-to-speed on managing our group.

Our groups are really sort of hierarchical and, while groups.io doesn't directly support that, having the ability to sort the subgroups membership list by the subgroup would make it pretty easy to manage that. As an example, almost everyone who is in our organization is part of an announcement-only sub-group. Except for those who are part of a "friends" group who get their own special announcements only. If I could sort by the "friends" sub-group, I could quickly check that they are not part of the general "announcement" group.

roland


moderated Re: Preventing simultaneous revision of wiki page by more than one member #suggestion

KWKloeber
 

A HARD lockout, not a warning. Folks/ignorant/inattentive/malicious can and will ignore warnings. And the downside is that it‘s not detrimental to THEM, but to everyone else.

But in addition to it being hard, the lockout should also (like an online banking session) time out (with a huge warning) so that no one user could inadvertently lock the wiki page “forever.”  Wiki edits should also get plunked into a Draft location so that time-outs are saved.



Ken
 
Sent from my phone


moderated Repeating Calendar Event updating #suggestion

Michael Pavan
 

When updating a repeating Calendar Event,
the confirmation window "Edit Recurring Event" asks:

| Would you like to change only this event or all events in the series?
|
| "Only This Event" All other events in the series will remain the same.
| "All Events" All events in the series will be changed.

If one clicks on "All Events" that changes all past occurrences, as well as the current and future ones.
This is usually not accurate.
The past is history, and should not be changed.

There should be a way to update only the current and future occurrences.

Please add "This and Future Events" as an option.

[Mod note: Removed the #bug hashtag]


moderated Re: Preventing simultaneous revision of wiki page by more than one member #suggestion

 

There are many reasons I decided against a database for this. I won't list them here.
So it's not the issue.
Also, we are almost all done getting the bulk of the neighbor info into the list and we ourselves will seldom run into this synchronicity problem again. I do think something needs to be done about this for the sake of other groups and other use cases.
Thanks.

On Sun, Mar 22, 2020 at 6:20 AM Duane <txpigeon@...> wrote:
On Sun, Mar 22, 2020 at 01:45 AM, J_Catlady wrote:
It became very real tonight after asking neighbors to input their info
It seems to me that a database/table might be a better choice for this situation, depending on how much information is being added.  I did a quick test this morning and it's possible for one person to be editing their row while another is editing theirs and both are fine, no mingling.  The only time there will be a conflict is if a moderator is making a change while the row owner is also editing.  This results in the "last save wins" scenario.

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


moderated Re: Preventing simultaneous revision of wiki page by more than one member #suggestion

Duane
 

On Sun, Mar 22, 2020 at 01:45 AM, J_Catlady wrote:
It became very real tonight after asking neighbors to input their info
It seems to me that a database/table might be a better choice for this situation, depending on how much information is being added.  I did a quick test this morning and it's possible for one person to be editing their row while another is editing theirs and both are fine, no mingling.  The only time there will be a conflict is if a moderator is making a change while the row owner is also editing.  This results in the "last save wins" scenario.

Duane


moderated Re: Solving the overload issue (Selecting specific messages into two batches - Individual email vs. Full featured digest delivery) #suggestion

Homayon Reinhardt Chaudhry
 

Hi Ronaldo
Insisting on netiquette didn't work. They stumbled already over this unknown English term 'Netiquette'. "Nétiquette - c'est quoi là, de la censure? Je m'en fous..."
Segmenting messages into different batches and assign those to different ways of delivery would be a "solution possible".
But we can wait in these days, it's not urgent. Let's concentrate on really important issues. When the whole pandemic is hopefully over, lets look into it again. Until then we use the method recommended by Patti and you people stay all well.
Ciao
Homayon




-----Ursprüngliche Nachricht-----
Von: main@beta.groups.io [mailto:main@beta.groups.io] Im Auftrag von ro-esp
Gesendet: Samstag, 21. März 2020 00:29
An: main@beta.groups.io
Betreff: Re: [beta] Solving the overload issue (Selecting specific messages into two batches - Individual email vs. Full featured digest delivery) #suggestion

On Thu, Mar 19, 2020 at 08:09 PM, Homayon Reinhardt Chaudhry wrote:

Dear all

Our medical group
Unfortunately again and again members leave because they feel flooded
by a part of those mails containing rather little information
I'm not sure why you think there should be a technical solution, nor even whether one is possible. The way I do it is by insisting on netiquette ( unfortunately http://www.learn.to/quote doesn't work anymore), and by clearly stating in the group-description that "me too"-messages, "thank you"-messages and seasonal greetings are not allowed.

groetjes, Ronaldo


moderated Re: Preventing simultaneous revision of wiki page by more than one member #suggestion

 

Duane/Shal,

That's funny. I read the prior thread you posted and see that I was actively involved in it, even though no group of mine was using a wiki then. For me it was all hypothetical at that point. It became very real tonight after asking neighbors to input their info, and some of them went to a lot of effort to do it, and the result was an unholy mess lol.

Maybe it's time to finally do something about this.


On Sat, Mar 21, 2020 at 10:25 PM Duane <txpigeon@...> wrote:
On Sat, Mar 21, 2020 at 11:03 PM, J_Catlady wrote:
It would be nice if this could be controlled. I don't expect it any time soon but am just pointing out the problems this has been causing.
Yeah, that's been around for awhile, https://beta.groups.io/g/main/topic/4993391  It even made it to the Trello page about 3 years ago, https://trello.com/c/4MNUkqic/283

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


moderated Re: Preventing simultaneous revision of wiki page by more than one member #suggestion

 

J wrote:

When you compare revisions, you see, one after the other, people
wiping out each other's additions, shown by their being crossed out in
the compare.

It would be nice if this could be controlled.
This sounds familiar...
https://beta.groups.io/g/main/topic/4993391

One way to control this might be to use a warning system (soft locking) similar to the "claim" of a moderator to a pending message. The Wiki is a simpler case because there is no email interaction to handle. The first member to Edit a given Wiki page would "claim" it, causing any other member to see a warning banner if he/she also Edits that page.

One thing to consider is whether this should be a hard lock - preventing any other members from editing the page until the first member Saves or Discards his/her edit. The downside of a hard lock is that the page could end up locked indefinitely if there is no way to "break" the first member's claim.

In my own opinion, an "Are you sure?" type of soft lock would be adequate: warning the user of the other edit in progress but still allowing the judgement call to break an apparently "stale" claim.

Our neighborhood/block group has been having group members going into
the name/address directory for the block and adding their info, while
simultaneously someone else is doing the same thing, ...
Instead of locking, I'd actually prefer to control this by way of an automatic merge function; merging in the concurrent edits in the manner of a distributed version control system (DVCS) like Fossil. For use cases like J's (which I think are common) the various member's edits would (most likely) be non-overlapping spans of text, making it possible to automatically merge the changes without conflict.

Of course merge conflicts are a pain to handle; the challenge for implementing this method for the Wiki would be finding a way to signal the presence of a conflict and a means for manual resolution. A typical approach is to include both versions of the conflicting span with some markup to delimit each version of the span. That leaves it possible for someone editing the page later to resolve the conflict by editing that part of the text down to a single "correct" version.

Groups.io could encourage manual resolution of any merge conflict by providing a notification to both of the members involved in the conflicting edits. Maybe also the group moderators.

Shal


moderated Re: Preventing simultaneous revision of wiki page by more than one member #suggestion

Duane
 

On Sat, Mar 21, 2020 at 11:03 PM, J_Catlady wrote:
It would be nice if this could be controlled. I don't expect it any time soon but am just pointing out the problems this has been causing.
Yeah, that's been around for awhile, https://beta.groups.io/g/main/topic/4993391  It even made it to the Trello page about 3 years ago, https://trello.com/c/4MNUkqic/283

Duane


moderated Preventing simultaneous revision of wiki page by more than one member #suggestion

 

Our neighborhood/block group has been having group members going into the name/address directory for the block and adding their info, while simultaneously someone else is doing the same thing, and the end result is that both people's changes get wiped out because when they hit save, the other person's info is not yet in the version they're editing. Their info gets in, and then the same thing happens with the next (within the same minute) person's revisions. When you compare revisions, you see, one after the other, people wiping out each other's additions, shown by their being crossed out in the compare.

It would be nice if this could be controlled. I don't expect it any time soon but am just pointing out the problems this has been causing.
--
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: Site updates #changelog

Bob Bellizzi
 

Mark,
I really appreciate the changes in Database that you made. 
I especially like the highlight bar to the left of the row that is in focus on the map and the ability to "disappear" columns from the list view.
I would like to get some feedback on my other suggestions for Database changes that were made in the
Suggestion message number 24250, especially the ability to "force view mode or map mode upon opening by the database owner and also as a permanent setting.
Is there a way that the column titles would stay in place when one scrolls down through a database?

Bob Bellizzi


moderated Re: Delayed email delivery #outage

 

It was taking up to three hours as of last night.


On Mar 21, 2020, at 10:48 AM, Mark via Groups.Io <pitamakan@...> wrote:

Yep, I just sent a message to one of my groups via the web interface, and it immediately appeared in the online message list ... but the e-mailed version of the message still hasn't arrived.

Mark

--
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: Delayed email delivery #outage

Mark
 

Yep, I just sent a message to one of my groups via the web interface, and it immediately appeared in the online message list ... but the e-mailed version of the message still hasn't arrived.

Mark


moderated Direct Add to use Display Name specified instead of Past Member entry #suggestion

Andy Wedge
 

Hi Mark,

picking up on a GMF topic when you Direct Add a member the display name specified at the time is ignored if the email address is also in the past members list, it takes the display name from the past member entry. An individual display name can be changed easily but the OP on GMF had added around 100 new members and mistakenly switched the first and last names. Now he cannot delete them all and start again.

Is there a reason we cannot just take the display name used on the DA?

Thanks,
Andy


moderated Site updates #changelog

 

Changes to the site this week:

  • INTERNAL: Work on new Help Center and code to convert the new manuals from Google Docs to HTML.
  • CHANGE: In the database table page, replaced the individual visibility toggle buttons with a dropdown menu.
  • NEW: Database address columns have a default country.
  • CHANGE: Changed width of all selects on the website so that they are their natural width, not 100%, which was confusing to some and ugly to all.
  • CHANGE: For Multiple Choice, Multiple Select columns, use a series of checkboxes instead of a HTML select element.
  • CHANGE: Improved look of the database add row page.
  • NEW: Database columns have a new description field.
  • API: Added /getactivitylog endpoint.
  • API: The docs incorrectly left off the /get prefix for the subgroupcategories endpoints.
  • API: Passing in the type parameter to /getmembernotices would return a blank response.
  • BUGFIX: The database map wasn't working for Enterprise domains.
  • BUGFIX: If an address field in a database was set to a non-default color, the color would not show up in the add/edit row screen, potentially causing the labels to also disappear.

Stay safe everyone.

Mark


moderated #bug Gio iCal feed errors making GCal mad #bug #fixed

Dave Huseby <dhuseby@...>
 

Hello,

The Hyperledger community uses Groups.io for all of our mailing lists and community managed calendars. We like to use the .ics feeds from groups.io to populate a GCal plugin on our Confluence wiki. We're finding that GCal fails to render all of the events in the feed. I ran our iCal feed through an ics validator and found tons of errors:


After checking with the ics standard ( https://tools.ietf.org/html/rfc5545 ) it seems like the feed rendered by Groups.io is formatted correctly but the dates in the DTSTART and DTEND parameters seem way off (2017 and 2018). I suspect that the errors are what is causing GCal to refuse to render all of our events but there doesn't seem to be a pattern in that GCal doesn't like.

I would appreciate any help you can give us because we're facing the prospect of migrating back to GCal if we can't fix this soon.

Cheers!
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...