HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS, which is now in beta. ocPortal 9 will be superseded by Composr 10.

Head over to compo.sr for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.


v7.0.1 - Chatroom issues

Login / Search

 [ Join | More ]
 Add topic 
Posted
Rating:
#70345 (In Topic #14887)
Avatar

Community saint

I have come across the following questions/bugs/usability/functionality issues.

1) The default setting for private chatrooms are a real problem as far as I am concerned as it is far too easy to start what you think is a private chat room only to discover too late that it is not private. This is compounded by the fact that the Low-level permissions section is collapsed by default, which does not make sense because you will always have to make at least some permission changes.

Because by default the "Member allow list" is blank and "Usergroup allow list" has everyone selected, the default state is public. And if you add a member to the allow list and don't touch the usergroup allow list you are still  public.

Also, the usergroup allow list states "A list of usergroup-names which are allowed into the chatroom. If this is a public room, it must be left blank.", which is counter intuitive, you should be required to select all groups in order to be public.

Bottom line, member and user group allow lists should both default to blank, meaning that the chatroom starter is the only participant, and is therefore private by default.

2) The member allow list (and I assume disallow list) does not validate members. I started off by placing a comma separated list of users because I didn't really notice/pay attention to the second line, and I was allowed to save the chatroom without the user list being verified. For something as important as privacy, this really must be validated.

3) In IE I get the following javascript error when entering member lists.

Code

Message: Member not found.

Line: 319
Char: 172
Code: 0
.../themes/Green/templates_cached/EN/javascript.js


4) How do you close a chat room? If you can't why not? The chatroom starter (and admin/moderators) should have a "close this chatroom option" link amongst the other actions in action list.

5) When you press the "create private chatroom" button you should be given a simple clear confirmation popup showing which members/users will have access to the chatroom so that there can be no doubt in the chartoom creators mind.

6) I think the hidden box showing "add link, …, create new room" etc. should be expanded by default. I never remember to expand it because I just don't notice the expand button, and so I don't use the feature because they are not obvious.

7) The list of available chatrooms should clearly state if they are public/private. Once again to avoid confusion. While members may only be able to see chatrooms that are allowed to participate in, they should still know if it is a public/private chartoom.

8) On the moderation page, need to be able to range-select (i.e. click first in range then click last in range) to select a block of messages to delete. Clicking one by one can be a real pain.

9) What permissions control who can edit a private chatroom? Can't seem to find it anywhere.

10) Admin should have permission to enter/edit/moderate/delete any chatroom without resorting to su'ing (not that it always helps).

Playing around on my test site, I have accounts created by staff, that staff, or even admin, can not edit/moderate delete..

Do you have a Samsung Galaxy S / Galaxy S II ? If so, why not check out my ScreenFree FM Radio .
Back to the top
 
Posted
Rating:
#70385
Avatar

Most of these will be tackled in 7.1-final, good suggestions.

you should be required to select all groups in order to be public.

What if a group is added after-the-fact? (Rhetorical - I've decided not to change anything here)

How do you close a chat room?

You can't. As the note at top of form explains: "it will automatically be deleted when there has been no activity in it for 1 day."

When you press the "create private chatroom" button you should be given a simple clear confirmation popup showing which members/users will have access to the chatroom so that there can be no doubt in the chartoom creators mind.

It gets complex if you add one with a large usergroup, and generally this would be hard, new AJAX code adding, new files, etc. So I am simply putting a member count/summary after each usergroup in the list so you can get a better idea from that.

I think the hidden box showing "add link, …, create new room" etc. should be expanded by default. I never remember to expand it because I just don't notice the expand button, and so I don't use the feature because they are not obvious.

You could template that. Most people want minimalism.

On the moderation page, need to be able to range-select (i.e. click first in range then click last in range) to select a block of messages to delete. Clicking one by one can be a real pain.

There's a 'Delete all messages' link at the bottom. I can't see a common enough use case to justify donating the development time for it, but as always if someone has a budget…

What permissions control who can edit a private chatroom? Can't seem to find it anywhere.

'moderate_my_private_rooms'

Admin should have permission to enter/edit/moderate/delete any chatroom without resorting to su'ing (not that it always helps).

They can – just tested.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#70391
Avatar

Community saint

you should be required to select all groups in order to be public.

What if a group is added after-the-fact? (Rhetorical - I've decided not to change anything here)
I see your point, but it just still does not sit right with me. Maybe you can untick a checkbox to make it public (and disable the list box) and leave the enabled list box for inclusions only. Leaving the list blank will (and already has) lead to confusion.

How do you close a chat room?

You can't. As the note at top of form explains: "it will automatically be deleted when there has been no activity in it for 1 day."

But there is the "Private room deletion time - (0 for no deletion)" option. Which means thet you should be able to close that room.

Also, you may have a private chat room that just won't die because people keep yapping on, and keep going over the same ground. You should be able to close it, which is much more graceful then deleting it from right under their feet.

When you press the "create private chatroom" button you should be given a simple clear confirmation popup showing which members/users will have access to the chatroom so that there can be no doubt in the chartoom creators mind.

It gets complex if you add one with a large usergroup, and generally this would be hard, new AJAX code adding, new files, etc. So I am simply putting a member count/summary after each usergroup in the list so you can get a better idea from that.

That compromise works for me!

I think the hidden box showing "add link, …, create new room" etc. should be expanded by default. I never remember to expand it because I just don't notice the expand button, and so I don't use the feature because they are not obvious.

You could template that. Most people want minimalism.

I know I can template it, but I would have thought that most people would want to see the options.

I know, this is just personal choice/perception.

On the moderation page, need to be able to range-select (i.e. click first in range then click last in range) to select a block of messages to delete. Clicking one by one can be a real pain.

There's a 'Delete all messages' link at the bottom. I can't see a common enough use case to justify donating the development time for it, but as always if someone has a budget…

I was thinking of a flame war scenario where you may have a chunk of rubish in an otherwise good room.

But yeah, how common is that?
What permissions control who can edit a private chatroom? Can't seem to find it anywhere.

'moderate_my_private_rooms'

I have staff with moderate_my_private_rooms already set but they can not delete, which is why I thought there may be another permission involved.

Admin should have permission to enter/edit/moderate/delete any chatroom without resorting to su'ing (not that it always helps).

They can – just tested.

I was sure that they could too (admin is god after all :) ), but admin can't for me.

For example, as a test, staff_member_1 created a chatroom with staff_member_1 as the only allowed member listed (just so that its not blank and therefore not public). They can enter the room but not edit/delete it.

Admin can not enter the room, can only see it listed on the moderation page, but can't do anything with it (gets an " "admin" does not have access to enter this chatroom." error).

Do you have a Samsung Galaxy S / Galaxy S II ? If so, why not check out my ScreenFree FM Radio .
Back to the top
 
Posted
Rating:
#70395
Avatar

I see your point, but it just still does not sit right with me. Maybe you can untick a checkbox to make it public (and disable the list box) and leave the enabled list box for inclusions only. Leaving the list blank will (and already has) lead to confusion.

I think the main problem is that it was public by default because no members were allocated. Your suggestion to add the owner to the list automatically works well to do that. The fact that no groups are then selected is fine because it will still not be public due to the owner being in the user list. To make it public you have to explicitly wipe the owner out of the allow list of users so that both the allow list of users and the allow list of groups is blank. Which you could argue is confusing, but it's not a common use case anyway on this form so I think it's fine.

But there is the "Private room deletion time - (0 for no deletion)" option. Which means thet you should be able to close that room.

Ah yes, the message makes no sense in this case, so I have removed it in this case. But what you're asking for is a new feature. I suggest you just make a very large setting for the auto-delete-time instead.

You should be able to close it, which is much more graceful then deleting it from right under their feet.

You could change the permissions to shut them up until it auto-deletes.

I know that's not obvious, but we don't design ocPortal with the mind that it's going to be the best chat system ever (or ecommerce system, or forum system), we design it to have the best range of solid features that are good enough for the common cases on the majority of sites (the majority of sites won't have lots of people creating lots of private chat rooms). Frankly, we could not afford to do otherwise except when we have clients who put us on a project where a particular system is a key part of their site offering – in which cases the extra niceties will likely get fed back into the core code at some point.
I know I've made a similar point a few times recently, but I like to answer each topic thoroughly on it's own. There is of course another option – we do allow external contributions. So if some other programmer adds some features and wants to donate their code back to the project (after a code review), it could have the same effect.

I have staff with moderate_my_private_rooms already set but they can not delete, which is why I thought there may be another permission involved.
&
I was sure that they could too (admin is god after all  ), but admin can't for me.

I'll ensure these are sorted.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#70406
Avatar

Community saint

I see your point, but it just still does not sit right with me. Maybe you can untick a checkbox to make it public (and disable the list box) and leave the enabled list box for inclusions only. Leaving the list blank will (and already has) lead to confusion.
I think the main problem is that it was public by default because no members were allocated. Your suggestion to add the owner to the list automatically works well to do that. The fact that no groups are then selected is fine because it will still not be public due to the owner being in the user list. To make it public you have to explicitly wipe the owner out of the allow list of users so that both the allow list of users and the allow list of groups is blank. Which you could argue is confusing, but it's not a common use case anyway on this form so I think it's fine.
Ok, scrap my comment. I was getting a little confused about the interrelationship of the member list and the group list. Because the statement "A list of usergroup-names which are allowed into the chatroom. If this is a public room, it must be left blank." doesn't state anything about an "unless there are members in the member list" scenario, it kept throwing me.
Ah yes, the message makes no sense in this case, so I have removed it in this case. But what you're asking for is a new feature. I suggest you just make a very large setting for the auto-delete-time instead.
Yep, just a matter of getting mixed signals.
I know that's not obvious, but we don't design ocPortal with the mind that it's going to be the best chat system ever…
I know, but you encourage us to give feedback and report issues, so I do  :lol:  :thumbs: .

Do you have a Samsung Galaxy S / Galaxy S II ? If so, why not check out my ScreenFree FM Radio .
Back to the top
 
1 guests and 0 members have just viewed this: None
Control functions:

Quick reply   Contract

Your name:
Your message: