Date   

moderated Re: extend "claimed by" feature for pending messages to pending members #suggestion

 

On Tue, Feb 5, 2019 at 12:48 PM, Mark Fletcher wrote:

What action would trigger the claiming?

J responded:

Mark, I'd already asked myself that hard question and figured I'd leave it to you to figure out. :) Thinking about it, I don't think just clicking on it should trigger the claim. This does seem complicated. Maybe there could be an explicit "edit member page" function, like with editing a message, and clicking on that would trigger a claim? I'll think more about it.
--
J

I had pondered that as well, and like J, I wanted to see what your thoughts were first. I don't think that simply opening a Pending Approval should trigger a claim. I am a moderator on several groups where I will look at a request, and if I'm not sure, I'll just leave it for the owner.

But I think if a message is sent or any other action taken, that should act as a claim. I think it would also be helpful to have a 'claim member approval' check box for those cases where there are questions, but no action is immediately taken. I'm assuming an owner would be able to override this claim.

Dano


moderated Re: extend "claimed by" feature for pending messages to pending members #suggestion

 

I like Shal's idea and maybe it could also be explicitly extended to editing messages as well (no real change in functionality but the moderator doing the editing would be made aware of the claim).
--
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: extend "claimed by" feature for pending messages to pending members #suggestion

 

Mark,


What action would trigger the claiming?

I would prefer an explicit Claim action.

It could be available in the Actions menu for selected people in the Pending list, and also a button when you open a given person's member page. 


And then, when someone else does the same, and then tries to approve/deny the subscription, they get a warning?

The Claim action could be unavailable after first use (for a given applicant). The Approve/Deny should get a warning, but still be possible (in case the moderator who claimed it becomes unavailable for any reason). Approve/deny by email against a claimed applicant should probably bounce, as with pending messages.
Shal


moderated Re: extend "claimed by" feature for pending messages to pending members #suggestion

 

On Tue, Feb 5, 2019 at 12:48 PM, Mark Fletcher wrote:
What action would trigger the claiming?
Mark, I'd already asked myself that hard question and figured I'd leave it to you to figure out. :) Thinking about it, I don't think just clicking on it should trigger the claim. This does seem complicated. Maybe there could be an explicit "edit member page" function, like with editing a message, and clicking on that would trigger a claim? I'll think more about it. 
--
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: extend "claimed by" feature for pending messages to pending members #suggestion

 

On Tue, Jan 29, 2019 at 2:29 PM J_Catlady <j.olivia.catlady@...> wrote:
 So it would be convenient if pending members could be "claimed," just as editing off a pending message is claimed, to prevent other mods from trying to go into their page and set it up.


What action would trigger the claiming? Right now, with pending messages, the action of editing the message triggers a claim, not the act of simply viewing it. Then if someone else tries to do anything with that message on the web, they get a warning (via email the accept/reject options are denied completely). 

So, would clicking on the pending subscription to bring up the member page be the claiming act? And then, when someone else does the same, and then tries to approve/deny the subscription, they get a warning?

Thanks,
Mark 


moderated Re: don't send "good bye" message to member who applies and then "leaves"

 

Ok, some time just opened up (appointment cancelled).

On Mon, Feb 4, 2019 at 03:12 PM, Michael Pavan wrote:
I favor intuitive and clear terms.
Hard to argue with that, and I don't. :)

Unapproved should not be allowed on yet,
This is semantics. What does "allowed on" mean to you? They do get a member record. They don't receive group posts and can't access the group (depending, of course, on its settings vis-a-vis non-members). You can call that being "on" or not being on. The fact is that unapproved (i.e., pending) members (note the term "members") are treated differently. They just arent - yet - treated differently *enough* (i.e., in all needed ways), such as the one that's the subject of my thread here.

Commingling these different types of 'Members' complicates controlling what options they may exercise, and the notices and logs generated. They need to be on different paths.
That would be ideal but Mark has indicated - in other situations akin to this that I and/or others have brought up (although I think, mainly me) - that it's difficult because of the current internal handling of member records. Which I believe, at some point, it would be good to clean up/fix. Right now, it's  not gonna happen, so for now I will be satisfied with the bandaids I've suggested here.

Only if and when membership requests are approved, should they be (approved) Members and handled as such.
Semantics again. See above.

Would we also want to be able to Ban a pending member without having to approve them first?
You can ban members right now without them even having applied. Maybe I should have said "ban people." Or "ban email addresses," which would be more accurate. We use the term "members" around here to indicate everything from approved members to pending members to banned members. Two of those are not, strictly speaking, by your criterion, "members" at all.
 
--
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: don't send "good bye" message to member who applies and then "leaves"

 

Sorry, I’m just out of time on this and think I’ve made the situation pretty clear. I can try to amplify again tonight or tomorrow.

On Feb 4, 2019, at 3:25 PM, J_Catlady via Groups.Io <j.olivia.catlady=gmail.com@groups.io> wrote:

It’s all semantics.
On Feb 4, 2019, at 3:12 PM, Michael Pavan <@mjp> wrote:

Catlady,

I agree with your concerns that persons who are Unapproved or Banned should be handled differently than (approved) Members.

Unapproved should not be allowed on yet, and Banned should be removed from the paths (options available according to status) that (approved) Members use. Commingling these different types of 'Members' complicates controlling what options they may exercise, and the notices and logs generated. They need to be on different paths.

It should be simpler to write (and correctly use) the appropriate notices and logs when members' statuses are pre-sorted, rather than needing to backtrack to check. Consider how this looks as a Flow Chart.


As you said in #19703, Unapproved members do "need a way to delete their membership request".
Whether you call it 'unsubscribe', 'delete', 'withdraw' or something else is a lesser question, however:

'unsubscribe' implies that they are 'subscribed' such as (approved) Members are, and I agree that with 'unsubscription' currently comes notices and logs that are not appropriate for Unapproved members (pending membership requests).

'delete' implies deleting their membership request and (IMHO) no notices or logs - as if it never happened, contrary in part to what you wrote in #19704:
| -since mods still need to know the person deleted their request, change both the "left" notice and log entry to "deleted application".

'withdraw' recognizes removing their membership request with no need to say anything about notices and/or logs, which can be set up as desired.

Whatever term is chosen matters less than the function(s) it covers. I favor intuitive and clear terms.


Only if and when membership requests are approved, should they be (approved) Members and handled as such. Similarly when a Member is Banned, they would no longer be (approved) Members and handled appropriately different. (Would we also want to be able to Ban a pending member without having to approve them first?)








--
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: don't send "good bye" message to member who applies and then "leaves"

 

It’s all semantics.

On Feb 4, 2019, at 3:12 PM, Michael Pavan <@mjp> wrote:

Catlady,

I agree with your concerns that persons who are Unapproved or Banned should be handled differently than (approved) Members.

Unapproved should not be allowed on yet, and Banned should be removed from the paths (options available according to status) that (approved) Members use. Commingling these different types of 'Members' complicates controlling what options they may exercise, and the notices and logs generated. They need to be on different paths.

It should be simpler to write (and correctly use) the appropriate notices and logs when members' statuses are pre-sorted, rather than needing to backtrack to check. Consider how this looks as a Flow Chart.


As you said in #19703, Unapproved members do "need a way to delete their membership request".
Whether you call it 'unsubscribe', 'delete', 'withdraw' or something else is a lesser question, however:

'unsubscribe' implies that they are 'subscribed' such as (approved) Members are, and I agree that with 'unsubscription' currently comes notices and logs that are not appropriate for Unapproved members (pending membership requests).

'delete' implies deleting their membership request and (IMHO) no notices or logs - as if it never happened, contrary in part to what you wrote in #19704:
| -since mods still need to know the person deleted their request, change both the "left" notice and log entry to "deleted application".

'withdraw' recognizes removing their membership request with no need to say anything about notices and/or logs, which can be set up as desired.

Whatever term is chosen matters less than the function(s) it covers. I favor intuitive and clear terms.


Only if and when membership requests are approved, should they be (approved) Members and handled as such. Similarly when a Member is Banned, they would no longer be (approved) Members and handled appropriately different. (Would we also want to be able to Ban a pending member without having to approve them first?)







--
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: don't send "good bye" message to member who applies and then "leaves"

Michael Pavan
 

Catlady,

I agree with your concerns that persons who are Unapproved or Banned should be handled differently than (approved) Members.

Unapproved should not be allowed on yet, and Banned should be removed from the paths (options available according to status) that (approved) Members use. Commingling these different types of 'Members' complicates controlling what options they may exercise, and the notices and logs generated. They need to be on different paths.

It should be simpler to write (and correctly use) the appropriate notices and logs when members' statuses are pre-sorted, rather than needing to backtrack to check. Consider how this looks as a Flow Chart.


As you said in #19703, Unapproved members do "need a way to delete their membership request".
Whether you call it 'unsubscribe', 'delete', 'withdraw' or something else is a lesser question, however:

'unsubscribe' implies that they are 'subscribed' such as (approved) Members are, and I agree that with 'unsubscription' currently comes notices and logs that are not appropriate for Unapproved members (pending membership requests).

'delete' implies deleting their membership request and (IMHO) no notices or logs - as if it never happened, contrary in part to what you wrote in #19704:
| -since mods still need to know the person deleted their request, change both the "left" notice and log entry to "deleted application".

'withdraw' recognizes removing their membership request with no need to say anything about notices and/or logs, which can be set up as desired.

Whatever term is chosen matters less than the function(s) it covers. I favor intuitive and clear terms.


Only if and when membership requests are approved, should they be (approved) Members and handled as such. Similarly when a Member is Banned, they would no longer be (approved) Members and handled appropriately different. (Would we also want to be able to Ban a pending member without having to approve them first?)


moderated Re: Wiki requests

Duane
 

On Mon, Feb 4, 2019 at 11:42 AM, Ken Kloeber wrote:
please add the “Confirm” warning to the “X Discard” the edited page button
If so, please make it optional.  Yes, I realize it's only 1 click, but ...

Duane


moderated Re: Wiki requests

KWKloeber
 

And please add the “Confirm” warning to the “X Discard” the edited page button?


On Sun, Feb 3, 2019 at 12:06 PM, Ken Kloeber wrote:
Additionally, seems  Delete and Discard might be forced way right?

On Tue, Jan 22, 2019 at 01:48 AM, Ken Kloeber wrote:
Sure would be more friendly/convenient if

Each display page
  • Had a small "Edit" button at the TOP (like MediaWiki) for logged-in users.


  • It's an unnecessary PITA to have to scroll to the end each time when making and saving multiple edits on a LONG page.

The photo editing options (contrast, etc) dialog box
  • Edits displayed real time, as you move the slide-bar
  • The slide-bar locked onto the keyboard L <=> R arrow keys.
  • Adding a border to and/or a (simple) frame to pix was an option.

While composing/editing
  • pages were saved in Wiki Drafts as are message drafts

The Wiki TOC display box
  • The title could display enhanced text (bolt, color, etc.)
  • Width could be user-set.  Or alternately, to simply have the box free-span across the page.
  • The box is too narrow for long headings to display nicely, especially if there are level 2.3.4 headings in the TOC.


PDFs
  • Could reside in a Wiki space, rather than in the Files space.
  • Could be hidden so they are available to only the wiki viewers or mods.


moderated Re: don't send "good bye" message to member who applies and then "leaves"

 

On Sun, Feb 3, 2019 at 09:49 PM, Michael Pavan wrote:
Semantics?
Not really.

Considering subscription requests as subscribed (although not approved) permits them to unsubscribe, which triggers the other problems complained about.
I think it doesn't matter what you call it, and I still think "unsubscribe" is the best term given than they're going to use the subscription page to do it. The fact of calling it "unsubscribe" is not what "triggers the other problems." You can make the unsubscribe function act differently on different classes of things. You can make it send the "good-bye" notice only if the member has been approved. You can make it log "withdrew application" instead of "left group" if the member has not been approved. Etc. It's not rocket science.
 
--
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: don't send "good bye" message to member who applies and then "leaves"

Michael Pavan
 

On Feb 3, 2019, at 11:33 PM, J_Catlady <@J_Catlady> wrote:

On Sun, Feb 3, 2019 at 08:27 PM, Michael Pavan wrote:
An unapproved member should be able to ‘withdraw’ their subscription request - ‘unsubscribe’ is only appropriate for one who is subscribed.
That should be just a matter of semantics, especially since the simplest implementation of withdrawing the application is to let the pending member go into their subscription page for the group and click on "unsubscribe." I have no problem with that aspect (i.e., using the word "unsubscribe" instead of "withdraw") and can see how it would be convoluted to change that one element of the subscription page just because a member is pending rather than approved.

However, the real problem is the way things are handled after that, and the fact that the system treats this not just as a matter of semantics, but actually goes on to treat the "unsubscribing" member as if they were an approved member.
Semantics?
Not really.

Considering subscription requests as subscribed (although not approved) permits them to unsubscribe, which triggers the other problems complained about.

There should be an appropriate way for them to exit from having their subscription request being considered - I suggest calling that way 'withdrawal', but another name would work.


moderated Re: don't send "good bye" message to member who applies and then "leaves"

 

On Sun, Feb 3, 2019 at 08:27 PM, Michael Pavan wrote:
An unapproved member should be able to ‘withdraw’ their subscription request - ‘unsubscribe’ is only appropriate for one who is subscribed.
That should be just a matter of semantics, especially since the simplest implementation of withdrawing the application is to let the pending member go into their subscription page for the group and click on "unsubscribe." I have no problem with that aspect (i.e., using the word "unsubscribe" instead of "withdraw") and can see how it would be convoluted to change that one element of the subscription page just because a member is pending rather than approved.

However, the real problem is the way things are handled after that, and the fact that the system treats this not just as a matter of semantics, but actually goes on to treat the "unsubscribing" member as if they were an approved member.
 
--
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: don't send "good bye" message to member who applies and then "leaves"

Michael Pavan
 

Isn't the fact that a person can unsubscribe before they have even become an approved member of the group the actual problem?
An unapproved member should be able to ‘withdraw’ their subscription request - ‘unsubscribe’ is only appropriate for one who is subscribed.


moderated Re: don't send "good bye" message to member who applies and then "leaves"

 

I don't think the whole thing will get sorted out soon (if at all), but I think the minimum bandaid for now is
-don't send the good-bye notice
-since mods still need to know the person deleted their request, change both the "left" notice and log entry to "deleted application"
-don't display the banner with "are you sure you want to unsubscribe" etc (just delete the application)
--
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: don't send "good bye" message to member who applies and then "leaves"

 

On Sun, Feb 3, 2019 at 05:30 PM, Gerald Boutin wrote:
Isn't the fact that a person can unsubscribe before they have even become an approved member of the group the actual problem?
It is sort of the actual problem, but it's embedded in what I think is a larger problem.

A pending member does need a way to delete their membership request, and the system calls that "unsubscribe." (Specifically, the group they're pending in shows up in their groups list, with "this subscription has not yet been approved" showing up in a top banner. They can then click "unsubscribe" by going into their subscription page for that group. The banner is another whole can of worms, BTW, since the banner does not properly disappear when they go into their real groups. But I posted about that in another thread.) 

But it's not wholly semantics. I think the real problem happens before they are allowed to "unsubscribe" (i.e., delete their request), namely: a member record for a pending member is created and is not completely properly dealt with in some of the ways I've described, here and elsewhere. This is similar to the problem of "Banned" members getting a member record, complete with a "join date" equal to the banning date, even if they've never been in the group. And with the whole weird way "banned" members are not necessarily removed, and need to be removed afterwards (from the "banned" list) and then need to be banned again.

I think there is something very funky going on internally with member records, and this is just part of it. Each one gets a bandaid put on it, but the problem pops up elsewhere.

For now, yes, you could simply not let a pending member "unsubscribe." But you'd still need a way for them to delete their membership request. Calling it "unsubscribe," and logging it as "left group," adds to the problem because of the confusion and miscommunication. But I don't think it's the root of the problem.
 
--
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: don't send "good bye" message to member who applies and then "leaves"

Gerald Boutin <groupsio@...>
 

Isn't the fact that a person can unsubscribe before they have even become an approved member of the group the actual problem? In other words, if that was fixed, then the feedback message would be a moot point.

--
Gerald


moderated Re: don't send "good bye" message to member who applies and then "leaves"

 

Adding this further issue: Using a test account, I applied to my restricted test group and then unsubscribed before I was approved. I got the following message, as if I had actually already been a member of the group. So this needs to be fixed as well. 

--
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: Wiki requests

KWKloeber
 

Additionally, seems  Delete and Discard might be forced way right?


On Tue, Jan 22, 2019 at 01:48 AM, Ken Kloeber wrote:
Sure would be more friendly/convenient if

Each display page
  • Had a small "Edit" button at the TOP (like MediaWiki) for logged-in users.


  • It's an unnecessary PITA to have to scroll to the end each time when making and saving multiple edits on a LONG page.

The photo editing options (contrast, etc) dialog box
  • Edits displayed real time, as you move the slide-bar
  • The slide-bar locked onto the keyboard L <=> R arrow keys.
  • Adding a border to and/or a (simple) frame to pix was an option.

While composing/editing
  • pages were saved in Wiki Drafts as are message drafts

The Wiki TOC display box
  • The title could display enhanced text (bolt, color, etc.)
  • Width could be user-set.  Or alternately, to simply have the box free-span across the page.
  • The box is too narrow for long headings to display nicely, especially if there are level 2.3.4 headings in the TOC.


PDFs
  • Could reside in a Wiki space, rather than in the Files space.
  • Could be hidden so they are available to only the wiki viewers or mods.