Date   

moderated Re: Reply via email to topic with hashtag set to "reply only to sender" lacks"Private:" in message title #bug

 

Christos,
I’m talking about when the person just hits “Reply.” 


On Jun 14, 2022, at 6:29 PM, Christos Psarras <christos@...> wrote:



On 2022-06-14 19:49, Janet_Catlady via groups.io wrote:
On Tue, Jun 14, 2022 at 03:53 PM, Christos Psarras wrote:
it already does that in the footer link
I don't know about that, but the emailed message itself has no "Private": prefix.
 

You must be talking about something else then because it does in my case when I click on that footer link, on either message version, and in both Tbird or Gmail, in both cases the message composition comes up with the Private prefix.

You are more than welcome to temporarily join my test group and see it for yourself, if you want to do that email me privately.

Cheers,
Christos


--
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: Reply via email to topic with hashtag set to "reply only to sender" lacks"Private:" in message title #bug

 



On 2022-06-14 19:49, Janet_Catlady via groups.io wrote:
On Tue, Jun 14, 2022 at 03:53 PM, Christos Psarras wrote:
it already does that in the footer link
I don't know about that, but the emailed message itself has no "Private": prefix.
 

You must be talking about something else then because it does in my case when I click on that footer link, on either message version, and in both Tbird or Gmail, in both cases the message composition comes up with the Private prefix.

You are more than welcome to temporarily join my test group and see it for yourself, if you want to do that email me privately.

Cheers,
Christos


moderated Re: Reply via email to topic with hashtag set to "reply only to sender" lacks"Private:" in message title #bug

 

On Tue, Jun 14, 2022 at 03:53 PM, Christos Psarras wrote:
it already does that in the footer link
I don't know about that, but the emailed message itself has no "Private": prefix.
 
--
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: Reply via email to topic with hashtag set to "reply only to sender" lacks"Private:" in message title #bug

 


do the same when the person just replies via any footer
For a footer, it probably could, with some programming. 
 
Wait a minute, it already does that in the footer link when I tested this.  In both a normal email (no hashtag), and in a ReplyToSender hashtagged one,  both footer "ReplyToSender" links included the Private prefix in the MailTo: ?Subject parameter.  I still have the test emails if needed.

Cheers,
Christos


moderated Re: Extra member data #suggestion

 

On Mon, Jun 13, 2022 at 11:06 PM, Mark Fletcher wrote:

A member can edit columns with either (2) or (3) checked at any time. If a
column has neither of those checked, the data is private and only
viewable/editable by group moderators (which they can do by viewing a member's
subscription page).
Why not allow a member to edit values in the case of (1) as well, even if it's only viewable by moderators and is not required to join the group? Maybe someone would want to keep their answers up to date even if they are optional and non-public.

As far as subgroups go, one theoretical application would be for a D&D type of group, where different stories are taking place in different subgroups, and extra columns in each subgroup could define aspects of the character the user is playing in that subgroup, for easy reference. I don't know if anyone will actually do that, though. I'd lean toward whatever's easiest to implement.

JohnF


moderated Re: Reply via email to topic with hashtag set to "reply only to sender" lacks"Private:" in message title #bug

Duane
 

On Tue, Jun 14, 2022 at 04:35 PM, Janet_Catlady wrote:
do the same when the person just replies via any footer
For a footer, it probably could, with some programming.  The case that you're talking about is when someone hits Reply in their email program.  Groups.io has no control over that.

Duane


moderated Re: Reply via email to topic with hashtag set to "reply only to sender" lacks"Private:" in message title #bug

 

On Mon, Jun 13, 2022 at 03:37 PM, Duane wrote:
The Reply To Sender footer will activate something like
"mailto:user@...?subject=Private: Re: [group] original subject line", adding the Private: information to the subject line
I'm calling it a bug until I understand why it's not, and forgive my denseness, but I still don't.:-) As you say, groups.io is adding "Private:" because it knows the person is using Reply to Sender. So why can't groups.io can't "know," for any topic with the private hashtag, that it needs to do the same when the person just replies via any footer? Groups.io always knows which topic a person is replying to - it knows a topic is locked and can bounce the email, it knows a topic is private and will send the reply privately, etc - so I still don't understand why it can't do this, too. I will bow out of this now.
 
--
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: Member subscription colors #update

 

On Mon, Jun 13, 2022 at 10:08 PM Andy Wedge <andy_wedge@...> wrote:

If subgroup member has their colour changed to 'no colour' and the default sub settings for the subgroup are 'no colour' then the subgroup member colour should be inherited from the main group. This way it works the same as resetting a (sub)group profile when the values are inherited from the higher level.

This has been fixed.

Thanks,
Mark 


moderated Re: Display Width in a Database Column #suggestion

Bruce Bowman
 

On Tue, Jun 14, 2022 at 02:38 AM, Dan Tucker wrote:
I strongly endorse/support using characters as the unit-of-measure when offering measurement of column width in Groups.io situations.
This is very difficult to implement in html. I don't know how to rectify this with the fact that a group member can vary his browser's font and/or zoom settings. At best, you would likely have to force the use of a monospaced font.

Please also consider that some column data types do not consist of characters at all.

Regards,
Bruce


moderated Re: Extra member data #suggestion

Andy Wedge
 

On Tue, Jun 14, 2022 at 05:06 AM, Mark Fletcher wrote:

Here are my questions:

  • Does this make sense?
  • Am I missing any functionality with this?
  • Importantly, how do I handle this information with subgroups? Does the extra data in the parent group also show up in each subgroup? Or should you be able to define different columns for each subgroup?

My initial thoughts:

on (1): having the ability to list more columns on the member list would be useful. If this was made to work the same way as a database by using a 'Visible' button it would standardise the approach and make it more flexible.   Any columns displayed should be sortable. Being able to filter on the additional columns would be helpful and if they are user definable, then filtering on a value being present rather than the value itself, would be good. One column I would like to see added is an indicator of whether or not a member has moderator notes attached.

on (1): will these new columns be exposed to the getmember and updatemember API endpoints? One extra value I would like to hold for my group members is a club membership expiry date and it would be a very onerous task to initially set and then maintain that via the website for 1100+ members.

on (2): If a value is required for someone to join a group, how does this impact or change the Direct Add functionality for a main group? All new members to my group are Direct Added initially. We don't use invites and join requests are only approved if they had been Direct Added before but left for some reason. (This allows me to distinguish between new and returning members when I do my monthly analysis of the activity log).

on (2) & (3): There seems to be some confusion/overlap between information possibly wanted to for group management purposes and user profile information which a member can choose to share. As Glenn pointed out, a member may provide some information to enable them to join a group that they don't wish to have visible on their profile. Having (2) & (3) checked would take that choice away from them and may discourage use of the Directory altogether.

For subgroups, I would say that they should have the same additional columns for members as the main group given that a member must be in the main group to belong to a subgroup. A subgroup would inherit the columns and values from the main group. The inheritance of a value for a subgroup member would be determined by whether or not a value is specified in the default sub settings for the subgroup. This would allow different values to be used in subgroups where needed and make them work in the same way as user profiles and the recently introduced member colours.

Overall, I think having the ability to define additional fields for member records, being able to decide which ones appear on the member list and being able to filter and sort them would be a great step forward.

That's all for now. 

Regards
Andy


moderated Re: Display Width in a Database Column #suggestion

 

I’d like to weigh in on this. With no real comparator to compare the difference between characters - a highly and readily visible quantity, and pixels - a completely invisible and unknown quantity to most users, it is somewhat more difficult to set up cell/column widths.
I strongly endorse/support using characters as the unit-of-measure when offering measurement of column width in Groups.io situations.

Yes, I know what pixels are, but I cannot describe how many pixels it might take to accommodate this entry, for example: "July 4, 2022" I can, however, tell you that it consumes 12 characters of space (between the quotation marks). It's like defining the difference between 'computer language' and 'ordinary language.'
 

On Mon, Jun 13, 2022 at 15:27 Bruce Bowman <bruce.bowman@...> wrote:
Mark -- The Display Width of a database column is defined in terms of pixels. When editing table properties, it would be helpful if the text immediately below the entry field said that.

Folks almost invariably assume it's in either text characters or percent of full width.

Thanks for your consideration,
Bruce


moderated Re: Member subscription colors #update

Andy Wedge
 

Hi Mark,


On Thu, Jun 2, 2022 at 06:21 PM, Mark Fletcher wrote:
I have updated the site. If a subgroup does not have a default color set, setting the parent subscription's color will now propagate that to the subgroup subscription.
I found a scenario where the colours are not propagated in the way I expected and so don't work in the same way as profile information:

If subgroup member has their colour changed to 'no colour' and the default sub settings for the subgroup are 'no colour' then the subgroup member colour should be inherited from the main group. This way it works the same as resetting a (sub)group profile when the values are inherited from the higher level.

Regards
Andy


moderated Re: Extra member data #suggestion

Glenn Glazer
 

On 06/13/2022 21:06, Mark Fletcher wrote:

With this new feature, which will be for premium groups, in the Default Sub Settings page, you will be able to set up extra member columns, much like you can currently define columns in a database. You can specify the data type for each column, just like in databases (ie: single line, paragraph, address, multi select, etc). And there are 3 checkboxes for each column:

  • (1) Default Hidden, which means the column will not show up in the group Members page
  • (2) Answer required to join the group, which means that when someone wants to join the group via the Groups.io website, they will be asked to specify this field
  • (3) Viewable in a member's profile, which means that when viewing a member's profile, via the Directory or elsewhere, this data will show up

A member can edit columns with either (2) or (3) checked at any time. If a column has neither of those checked, the data is private and only viewable/editable by group moderators (which they can do by viewing a member's subscription page).

Here are my questions:

  • Does this make sense?
  • Am I missing any functionality with this?
  • Importantly, how do I handle this information with subgroups? Does the extra data in the parent group also show up in each subgroup? Or should you be able to define different columns for each subgroup?

Thanks,
Mark


Some thoughts:

1) I think visibility (3) should be toggle-able by the member, as they may not want everyone to know whatever it is (e.g., what if it is a phone number, birth date or some other piece of PII?) even if others are okay with sharing the same information about themselves.
2) I assume none of this changes the identity page which is global to all groups one is a member of, correct?
3) With respect to subgroups, I would let each subgroup define, let the group define and then have the member page in the group actually show the composition of the group columns and whatever subgroups one is in, appropriately marked and grouped by subgroup.
4) Would one be able to do a member search based on these fields? What about sorting by one or multiple keys/columns?

Best,

Glenn
P.S. Joke for those who know: if it's a database, then can I query it with SQL?

--
PG&E Delenda Est


moderated Extra member data #suggestion

 

Hi All,

For the past few weeks, I've been working on the ability to associate additional information with each member, and I need some help.

With this new feature, which will be for premium groups, in the Default Sub Settings page, you will be able to set up extra member columns, much like you can currently define columns in a database. You can specify the data type for each column, just like in databases (ie: single line, paragraph, address, multi select, etc). And there are 3 checkboxes for each column:

  • (1) Default Hidden, which means the column will not show up in the group Members page
  • (2) Answer required to join the group, which means that when someone wants to join the group via the Groups.io website, they will be asked to specify this field
  • (3) Viewable in a member's profile, which means that when viewing a member's profile, via the Directory or elsewhere, this data will show up

A member can edit columns with either (2) or (3) checked at any time. If a column has neither of those checked, the data is private and only viewable/editable by group moderators (which they can do by viewing a member's subscription page).

Here are my questions:

  • Does this make sense?
  • Am I missing any functionality with this?
  • Importantly, how do I handle this information with subgroups? Does the extra data in the parent group also show up in each subgroup? Or should you be able to define different columns for each subgroup?

Thanks,
Mark


moderated Display Width in a Database Column #suggestion

Bruce Bowman
 

Mark -- The Display Width of a database column is defined in terms of pixels. When editing table properties, it would be helpful if the text immediately below the entry field said that.

Folks almost invariably assume it's in either text characters or percent of full width.

Thanks for your consideration,
Bruce


moderated Re: Reply via email to topic with hashtag set to "reply only to sender" lacks"Private:" in message title #bug

Duane
 

On Mon, Jun 13, 2022 at 04:29 PM, Janet_Catlady wrote:
not the bug I'm reporting.
As we've tried to explain, it's not a bug, it's the way email works.  In order for a private email reply, via the reply button to be marked as such, there would have to be a way to change the subject line in the email program.  That's not something Groups.io has any control over (and likely doesn't want!).  The Reply To Sender footer will activate something like
"mailto:user@...?subject=Private: Re: [group] original subject line", adding the Private: information to the subject line.  The reply button just uses the Reply-To header for the address and the original subject line for the subject line.

Now if Mark gets his dream email system set up (after Groups.io is perfected and we all use that system), we may be able to do what you want. ;>)

Duane


moderated Re: Reply via email to topic with hashtag set to "reply only to sender" lacks"Private:" in message title #bug

 

J,

Here's how I understand the process, if it helps clear things up any.

A1. On email messages, when the message gets adjusted/formatted per the group settings (including adding the footers) before sending out, the GIO code assigns a MailTo: URL to the footer's "Reply to Sender" text.  Since that link is a "known quantity" variable, i.e. we know it's going to go privately to the message sender, we take advantage of the capability of a MailTo: link to also include the reply email subject as a parameter hence we pass the original subject with Private, along with the address to send it to.  The ReplyToSender footer link doesn't care whether the subject contains a hashtag, or the group ReplyTo setting is set to whatever, or what the headers specify for ReplyTo, etc, all it cares is the recipients email address (minimum required), and the optional Subject parameter.

A2. On online replies, the "ReplyToSender" button works the same way pretty-much as A1, all the necessary info is also known to GIO beforehand so no problems prefixing Private.

B. The discrepancy happens when one uses the "Reply" button of the email client vs the "Reply" button of online, when the message contains a hashtag set to ReplyToSender. 

Online, the GIO code sees the hashtag and has access to its settings so it knows now a reply will go to the sender, so it prefixes the reply with Private as it uses the same "logic" as in A1/A2.

But when the email client gets the email, while it may determine there is a hashtag in the subject, it doesn't know it's set to ReplyToSender, plus there is no special code on that email client anyway to adjust the subject, so clicking on the email client's "reply" button does the default behavior, use the original subject as is and just prefix Re:, and use the ReplyTo value to send it to (if there, else use the From: value).  And because that reply now goes directly to the sender it never re-enters the GIO ecosystem so there's no opportunity to automatically add the Private prefix.

It's that lack of what-to-do code on the email client's part which causes this, not anything can be done about it really.  What Dwayne suggested could be one solution but I agree with what he said, it would cause more confusion more than likely.

Cheers,
Christos


moderated Re: Reply via email to topic with hashtag set to "reply only to sender" lacks"Private:" in message title #bug

 

On Mon, Jun 13, 2022 at 02:26 PM, Andy Wedge wrote:
There is nothing to stop a user sending an email that way from editing the subject and removing the word Private before hitting Send.
But that's not what's happening. My members certainly aren't doing that. And in my tests, I certainly didn't do that. And yet it doesn't appear when the private reply is due to a private hashtag.

And - we seem to be simply not on the same wavelength with this so I'll exit this sub-thread after this - the message you received from me was not private so the word "Private" should not be there in the first place. But that seems to be an issue with your example, not the bug I'm reporting.
 
--
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: Reply via email to topic with hashtag set to "reply only to sender" lacks"Private:" in message title #bug

Andy Wedge
 

On Mon, Jun 13, 2022 at 09:01 PM, Janet_Catlady wrote:
Well, first, and again: I did not send you a private message. So I don't know what it's doing there at all in this case. :-)
No you didn't and I never said you did.
In your OP you said:
:
When someone intentionally sends a private reply via email to a topic by clicking "reply to sender," the prefix is correctly attached.
What I am saying is that the 'Private' prefix is added because it is specified in the Reply to Sender (Mailto:) link.  There is nothing to stop a user sending an email that way from editing the subject and removing the word Private before hitting Send. Someone using the Groups.io website can hit the Private button and then remove the word Private from the message subject before sending too. You cannot guarantee on the word 'Private' being there.

Regards
Andy


moderated Re: Topics with no messages #bug

Andy I
 

Maybe this is a stupid question, but what does it mean to have a group URL that looks like a subdirectory of Topics?  I think I have never seen that, in other groups.  How did you get "temp" and "temp2" subdirectories?  What is the "topics-test page" where you say you did the merges?

Andy