Date   

moderated Re: Make Sticky Topic show at top of Messages view #suggestion

 

On Mon, Aug 17, 2020 at 04:02 PM, Epicatt2 wrote:
Such a problem as you suggest just above, Catlady, would not be the case were the the 'sticky' option in Message view only be permitted for use by the moderators
Right, but what "option"? The request is that Messages view be subject to sticky order, period. For my group and some others, that would ruin Messages view and render it practically useless (or render stickies useless, one or the other). I would not be opposed to an option, but an option is not what's being proposed here.
 
--
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: Make Sticky Topic show at top of Messages view #suggestion

Epicatt2
 

On Sun, Aug 16, 2020 at 04:46 PM, J_Catlady wrote:


If you do that, it’s going to take scrolling through multiple pages to get
past the sticky messages in some groups I know of.
== ==

Such a problem as you suggest just above, Catlady, would not be the case were the the 'sticky' option in Message view only be permitted for use by the moderators and owner(s) of a group. And it should able to be toggled on or off separately from pinned messages on the Topics view.

Of course it's also important that the moderators/owners make sure to un-pin those posts whose immediacy has been served and thus avoid the excessive clutter that you are concerned about.

Just FWIW . . .

Regards,

Paul M.
Owner, CostaRicaLiving
==


moderated "OR" in Direct Add page search box #bug

Dan Halbert
 

In the Members page search box, [ Smith OR Jones ] will find all the Smith or Jones members.

But in the Direct Add page search box for a subgroup , when both Smith and Jones are not in the subgroup, searching [ Smith OR Jones ] does not list either as being addable non-members of the subgroup.

(Ref https://beta.groups.io/g/main/topic/76231422#25987)


moderated Re: Direct Add to subgroup: stay on Direct Add page after adding; allow bulk searches #suggestion #done

Dan Halbert
 

You can use OR in a search also.  There is an outstanding issue with the search strings though (see https://beta.groups.io/g/main/topic/71860654) and it can help if you put your search string in quotes. Searching for something like "Smith" OR "Jones" OR "Harris" works fine for me.

Indeed, [ Smith OR Jones ] works in the Members search box. But I had tried "OR" n the Direct Add page search box of a subgroup, and there it does not work when trying find either Smith or Jones as an un-added member. This may be a bug and I will open a new topic for that.

Dan


moderated Re: Direct Add to subgroup: stay on Direct Add page after adding; allow bulk searches #suggestion #done

Andy Wedge
 

On Sun, Aug 16, 2020 at 09:47 PM, Dan Halbert wrote:

 After I click "Add Member", the web interface goes back to the Members page, instead of staying on the Direct Add page. ... ... It would be nice if the interface stayed on the Direct Add page.

Agreed.

It would be nice if I could do a bulk search. I could search for multiple people, as both names as email addresses.
If you are an owner or moderator, your search includes names and email addresses.


Right now, the search box does an AND of all the search terms, so I can't search for multiple people with different names.

You can use OR in a search also.  There is an outstanding issue with the search strings though (see https://beta.groups.io/g/main/topic/71860654) and it can help if you put your search string in quotes. Searching for something like "Smith" OR "Jones" OR "Harris" works fine for me.


Suppose, for instance, that the search box were multi-line:

This would take up too much space on mobile devices where screen real estate is at a premium so I wouldn't go for this.


Andy


moderated Direct Add to subgroup: stay on Direct Add page after adding; allow bulk searches #suggestion #done

Dan Halbert
 

I am often asked to add multiple people from the main group to a subgroup. Currently this can be somewhat tedious. I have two ideas that I think might make this easier:

1.  Right now I search for each person, check their box, and add them, one at a time. After I click "Add Member", the web interface goes back to the Members page, instead of staying on the Direct Add page. So I have to click "Direct Add' In the left sidebar, and go back to that page. It would be nice if the interface stayed on the Direct Add page. This seems like an easy change.

2. It would be nice if I could do a bulk search. I could search for multiple people, as both names as email addresses. Right now, the search box does an AND of all the search terms, so I can't search for multiple people with different names. Suppose, for instance, that the search box were multi-line: all the terms on a single line would do an AND search, and the results for each line would be OR'd. For example:

Cooper
john.smith@...
Sam Jones

might return:

John Cooper   jcooper@...
Jane Cooper   janec@...
John Smith     john.smith@...
Samuel Jones  sj@...


moderated Re: Make Sticky Topic show at top of Messages view #suggestion

 

If you do that, it’s going to take scrolling through multiple pages to get past the sticky messages in some groups I know of. Thst is going to be a PITA.

On Aug 16, 2020, at 12:18 PM, Epicatt2 <stanhopi@gmail.com> wrote:

On Sun, Aug 16, 2020 at 12:41 PM, Steve wrote:


I'll add my "voice" to have the "sticky" option to also apply to the "Messages"
view. This would make it so much easier for me to keep important items in
front of the group, almost all of whom use the "Messages" view,
== ==
I'm also in agreement with having the 'sticky' option apply to 'Messages' as well as to 'Topics'.

In addition, I can see how that 'sticky' option might help to fill the gap left by 'Special Notices' for those members who are set to 'No Email.'

Regards,

Paul M.
Owner – CostaRicaLiving @ GIO
==


--
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: Make Sticky Topic show at top of Messages view #suggestion

Epicatt2
 

On Sun, Aug 16, 2020 at 12:41 PM, Steve wrote:


I'll add my "voice" to have the "sticky" option to also apply to the "Messages"
view. This would make it so much easier for me to keep important items in
front of the group, almost all of whom use the "Messages" view,
== ==
I'm also in agreement with having the 'sticky' option apply to 'Messages' as well as to 'Topics'.

In addition, I can see how that 'sticky' option might help to fill the gap left by 'Special Notices' for those members who are set to 'No Email.'

Regards,

Paul M.
Owner – CostaRicaLiving @ GIO
==


moderated Re: Make Sticky Topic show at top of Messages view #suggestion

 

I'll add my "voice" to have the "sticky" option to also apply to the "Messages" view. This would make it so much easier for me to keep important items in front of the group, almost all of whom use the "Messages" view, NOT the "Topics" view (so having a sticky only appear there, is useless for us).

If that change could be implemented, I would be "eternally" grateful and would even make a cat donation!


moderated Re: Moving Topics To Subgroups

Bob Bellizzi
 

If it happens occasionally,
You could copy & paste it into a msg in the subgroup
--

Bob Bellizzi


moderated Re: Moving Topics To Subgroups

Anthony Angelo
 

I guess no solution developed for this? Sometimes a topic is started in a main group that really should be sub-group focused. Moving it would be helpful.


moderated Re: Site updates #changelog

Mark Irving
 

You deserve the holday, Mark!

 - Mark

On Sat, Aug 15, 2020 at 05:16 AM, Mark Fletcher wrote:

I will be on vacation next week.


moderated Re: account display name vs group display name change issues #misc

 

Typo - should read “ is considering only changes by the user rather than by the user or a group moderator”


On Aug 15, 2020, at 1:35 AM, J_Catlady via groups.io <j.olivia.catlady@...> wrote:

Maybe the bug, or issue, is in how groups.io determines whether or not the user’s Display  Name in a group has been customized. In this case, it was customized not by the user but by a moderator. It seems the criterion for whether or not it’s been customized must be something other than “do they match.” So maybe it’s looking for the existence of a change action, and is considering only changes by the user as well as group moderators. This is a different animal from the rest of the group profile in that moderators, as well as the user themselves, can make changes to it.


On Aug 15, 2020, at 1:15 AM, J_Catlady via groups.io <j.olivia.catlady@...> wrote:

If that’s the intention, then I agree that this is a bug. Not sure whether it’s a bug or whether that documentation section is incorrect as applied to the Display Name. I’d always thought that the intention was for changes to the Display Name to propagate down regardless of prior customization, but glad to hear I might have been wrong.

We went through something like this awhile back with harvesting of.the name from the email address. Currently, the email name won’t be harvested if the Display Name has already been set. But previously, groups.io would take the name from any email and slap it into the Display Name wily nily. So this is similar and should also be fixed.


On Aug 15, 2020, at 12:23 AM, Andy Wedge <andy_wedge@...> wrote:

On Sat, Aug 15, 2020 at 05:30 AM, J_Catlady wrote:
I would do away with the ability to edit display names from the account page altogether.
No, I disagree.  The issue here is that display name changes in the account profile are propagated to (sub)group profiles regardless of whether a value has already been set in the (sub)group.  This is in contrast to how other profile fields are handled and contrary to what the highlighted note in point 5 of section Customizing your Groups.io account profile and individual group profiles in the Members' Manual states:

Note: Changes you make on this page also are applied to the corresponding fields in your individual group profiles unless you have customized those fields in those profiles.

So, this is actually a bug.

Andy


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


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


--
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: account display name vs group display name change issues #misc

 

Maybe the bug, or issue, is in how groups.io determines whether or not the user’s Display  Name in a group has been customized. In this case, it was customized not by the user but by a moderator. It seems the criterion for whether or not it’s been customized must be something other than “do they match.” So maybe it’s looking for the existence of a change action, and is considering only changes by the user as well as group moderators. This is a different animal from the rest of the group profile in that moderators, as well as the user themselves, can make changes to it.


On Aug 15, 2020, at 1:15 AM, J_Catlady via groups.io <j.olivia.catlady@...> wrote:

If that’s the intention, then I agree that this is a bug. Not sure whether it’s a bug or whether that documentation section is incorrect as applied to the Display Name. I’d always thought that the intention was for changes to the Display Name to propagate down regardless of prior customization, but glad to hear I might have been wrong.

We went through something like this awhile back with harvesting of.the name from the email address. Currently, the email name won’t be harvested if the Display Name has already been set. But previously, groups.io would take the name from any email and slap it into the Display Name wily nily. So this is similar and should also be fixed.


On Aug 15, 2020, at 12:23 AM, Andy Wedge <andy_wedge@...> wrote:

On Sat, Aug 15, 2020 at 05:30 AM, J_Catlady wrote:
I would do away with the ability to edit display names from the account page altogether.
No, I disagree.  The issue here is that display name changes in the account profile are propagated to (sub)group profiles regardless of whether a value has already been set in the (sub)group.  This is in contrast to how other profile fields are handled and contrary to what the highlighted note in point 5 of section Customizing your Groups.io account profile and individual group profiles in the Members' Manual states:

Note: Changes you make on this page also are applied to the corresponding fields in your individual group profiles unless you have customized those fields in those profiles.

So, this is actually a bug.

Andy


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


--
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: account display name vs group display name change issues #misc

 

If that’s the intention, then I agree that this is a bug. Not sure whether it’s a bug or whether that documentation section is incorrect as applied to the Display Name. I’d always thought that the intention was for changes to the Display Name to propagate down regardless of prior customization, but glad to hear I might have been wrong.

We went through something like this awhile back with harvesting of.the name from the email address. Currently, the email name won’t be harvested if the Display Name has already been set. But previously, groups.io would take the name from any email and slap it into the Display Name wily nily. So this is similar and should also be fixed.


On Aug 15, 2020, at 12:23 AM, Andy Wedge <andy_wedge@...> wrote:

On Sat, Aug 15, 2020 at 05:30 AM, J_Catlady wrote:
I would do away with the ability to edit display names from the account page altogether.
No, I disagree.  The issue here is that display name changes in the account profile are propagated to (sub)group profiles regardless of whether a value has already been set in the (sub)group.  This is in contrast to how other profile fields are handled and contrary to what the highlighted note in point 5 of section Customizing your Groups.io account profile and individual group profiles in the Members' Manual states:

Note: Changes you make on this page also are applied to the corresponding fields in your individual group profiles unless you have customized those fields in those profiles.

So, this is actually a bug.

Andy


--
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: account display name vs group display name change issues #misc

Andy Wedge
 

On Sat, Aug 15, 2020 at 05:30 AM, J_Catlady wrote:
I would do away with the ability to edit display names from the account page altogether.
No, I disagree.  The issue here is that display name changes in the account profile are propagated to (sub)group profiles regardless of whether a value has already been set in the (sub)group.  This is in contrast to how other profile fields are handled and contrary to what the highlighted note in point 5 of section Customizing your Groups.io account profile and individual group profiles in the Members' Manual states:

Note: Changes you make on this page also are applied to the corresponding fields in your individual group profiles unless you have customized those fields in those profiles.

So, this is actually a bug.

Andy


moderated Re: account display name vs group display name change issues #misc

 

Since ultimately and logically the Display Name is a group, and not an account, variable, I would do away with the ability to edit display names from the account page altogether. Let people set their user names in the account, because the user name is truly an account variable, bug their display names would be set per group. I know this sounds radical but this problem keeps popping up. Even when their display name has already been set in their account (and is not blank), if is problematic that any change to it percolates down to all their groups when often the groups have their Jen standard for display names. I know if other groups besides mine that have display name policies.


On Aug 14, 2020, at 8:07 PM, J_Catlady via groups.io <j.olivia.catlady@...> wrote:

The following happens a lot in our group:
1. Someone applies for membership.
2. We approve their membership and, in the process, set their Display Name to their name, their cat's name and gender, and their country, which is the standard for our group.
3. The member goes into their Account and edits their Display Name there, which at that point shows as blank, to whatever they want it to be, having no clue that it has already been set in one of their groups.
4. I (eventually) discover this and change it back in our group. (I always have to stop myself from slapping them on the wrist for violating our group guideline not to change their display name, because they thought it was completely blank and were just setting it.)

Is there any reasonable way of remedying this situation? Something like, "If the Account Display Name is blank, and the member sets it, don't change it in any groups where it's not blank"?
--
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


--
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 Site updates #changelog

 

Changes to the site this week:

  • INTERNAL: Revamped the login system for the admin dashboard to deal with a cross-site cookies issue.
  • CHANGE: Changed the From for all RSVP email notifications to be noreply@groups.io and added a Reply-To with the event organizer's email address, to fix DMARC issues.
  • INTERNAL: Added code to checker to look for orphan repeat events and delete them, to prevent ghost events from showing up in ICS files.
  • DOCS: Updates from Nina.
  • INTERNAL: Fix for logical replication timeout when extracting text from large PDF files for Files search.
  • CHANGE: Collapsed panels in the default sub settings page.
  • CHANGE: Some reorganization of the group settings page and all panels are now collapsable and collapsed by default.
  • BUGFIX: Fix file search pagination.
  • BUGFIX: Accounts with two factor authentication enabled could not log into enterprise groups with SSO set up.

I will be on vacation next week. The next #changelog will be sent the evening of August 28th.

Take care everyone.

Mark


moderated account display name vs group display name change issues #misc

 

The following happens a lot in our group:
1. Someone applies for membership.
2. We approve their membership and, in the process, set their Display Name to their name, their cat's name and gender, and their country, which is the standard for our group.
3. The member goes into their Account and edits their Display Name there, which at that point shows as blank, to whatever they want it to be, having no clue that it has already been set in one of their groups.
4. I (eventually) discover this and change it back in our group. (I always have to stop myself from slapping them on the wrist for violating our group guideline not to change their display name, because they thought it was completely blank and were just setting it.)

Is there any reasonable way of remedying this situation? Something like, "If the Account Display Name is blank, and the member sets it, don't change it in any groups where it's not blank"?
--
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: saving profile and other edits #suggestion

KWKloeber
 

Andy. TY

Okkkk,  Got it now. I was befuddled - there's no subgroup so there is no higher level -- I didn't think to look at the Account  (have never set any profile there.)

I doubt if many users would think Reset means "higher level."  Not fatal, but It might be helpful if on the Profile tab there was an explanation
(on a subgroup page) "A Reset defaults to your Group Profile" and
(on a Group page) "A Reset defaults to your Account Profile."

I tried it (AND figured if I left the tab I'd be safe; GIO wouldn't save the edit.)  Not so, GIO had saved the Reset edit (so I had to reenter everything.)
So (IMO) that's an inconsistency bug that could be cleaned up - 
If leaving the Membership tab doesn't save the edit, then likewise leaving the Group Profile tab shouldn't save the edit. OR there should be warnings, such as "Are you SURE? (your reset will be saved automatically.)"

3121 - 3140 of 28877