Date   

moderated Re: Retroactive Topic Locking? #misc #suggestion

 

Exactly. Turning off the setting is currently the *only* way to selectively unlock timed-out topics, even just one of them, that you want to reopen later, sometimes even much later. For me, this makes the feature unusable.

Of course the behavior is @preferable” to the alternative you propose. But for the feature to be usable over the long term (at least one person in this thread is new to it and hasn’t experienced the problem), there should be a different alternative - the alternative of allowing a topic to be selectively marked as “don’t time me out - have been selected as reopened.” (If that makes that particular topic immune to auto-locking fine. The mod can relock it by hand later if so desired.)

It’s because of this bug (and I’m still calling it a bug) that I eventually had to stop using the feature altogether. And trust me: there will eventually be mods, and probably are some, perhaps many of them, who manually unlock topics and find them locked the next day, think they’re going crazy bdvsuse they remember having locked it and lock it again, etc,  and do this repeatedly before they either report a false bug (“unlocked topic came back locked”) or (less likely) figure out that it’s a locking time-out and report *that* as a bug or a suggestion (as I’ve done before, at least once), or quit using the feature. Or resign themselves to the inconvenient truth that kicked topics are locked forever.


On Aug 19, 2020, at 6:21 AM, Bruce Bowman <bruce.bowman@...> wrote:

On Tue, Aug 18, 2020 at 11:21 PM, J_Catlady wrote:
It does not allow a moderator to manually unlock any topic that times out. If you unlock it by day, the feature [sic] goes back in that night like a sneaky little thief and locks it again based on the timestamp. This is a serious downside, if not actually a bug (I would call it one).
J -- Go back into settings, turn it back off, and your unlocked topics will remain unlocked.

I believe this behavior is preferable to having multiple topics mysteriously fail to lock when you change the group setting, for no other reason that you manually locked/unlocked them at some time in the past. Be careful what you wish for. 

Regards,
Bruce

--
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: Retroactive Topic Locking? #misc #suggestion

Bruce Bowman
 

On Tue, Aug 18, 2020 at 11:21 PM, J_Catlady wrote:
It does not allow a moderator to manually unlock any topic that times out. If you unlock it by day, the feature [sic] goes back in that night like a sneaky little thief and locks it again based on the timestamp. This is a serious downside, if not actually a bug (I would call it one).
J -- Go back into settings, turn it back off, and your unlocked topics will remain unlocked.

I believe this behavior is preferable to having multiple topics mysteriously fail to lock when you change the group setting, for no other reason that you manually locked/unlocked them at some time in the past. Be careful what you wish for. 

Regards,
Bruce


moderated Re: Retroactive Topic Locking? #misc #suggestion

Andy Wedge
 

On Tue, Aug 18, 2020 at 11:15 PM, Bruce Bowman wrote:
that setting is not applied in real time. Affected topics will be locked later, when the corresponding system job runs.
I use this feature to lock topics and it does indeed work, and works again if you unlock a topic as J says.  I'm not sure I would call re-locking a topic a bug though.

Andy


moderated Re: Retroactive Topic Locking? #misc #suggestion

 

Haha they will be locked overnight, alright. And if you decide, "oops you didn't want one or two of them locked," good luck unlocking them! They will be locked again the following night. And the following night. And the following night... You would not believe how long it took me to figure out that's what was happening when I used to manually unlock topics and find them locked again the next day lol.
--
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: Retroactive Topic Locking? #misc #suggestion

 

Unfortunately, as I've mentioned at least once in the past, the auto-lock feature is problematic. It should be *less*, not more "retroactive." It does not allow a moderator to manually unlock any topic that times out. If you unlock it by day, the feature [sic] goes back in that night like a sneaky little thief and locks it again based on the timestamp. This is a serious downside, if not actually a bug (I would call it one).
--
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: Retroactive Topic Locking? #misc #suggestion

Bruce Bowman
 

On Tue, Aug 18, 2020 at 05:31 PM, Bob Bellizzi wrote:
As a result, i recently realized what a great help Lock Topic would be and decided to try it prior to utilizing it on our 20 year old group with almost 170,000 messages and about 65,000 topics.
So I set it in motion in a test group and lo and behold, nothing changed.  I was able to reply to messages beyond the limit I set (10 days).
Leads me to believe that Lock Topic is not retroactive.
Bob -- Are you talking about the setting "Automatically Lock Topics Older Than XXX Days?"

If so, that setting is not applied in real time. Affected topics will be locked later, when the corresponding system job runs.

Hope this helps,
Bruce


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