Closed cfdp closed 7 years ago
Could we customize the "Sorry something went wrong"-text to fit the scenario - something like "It seems your counselor is not available yet, try again in a few minutes"
@benjamin-dk should the link be sent to the client by the site, or should we only expose it to the counselor who will send it to the user? If the former, the counselor should indicate the email of the user, right?
It is sent by the counselor so yes the email should be indicated.
On June 2, 2017 11:10:45 PM GMT+02:00, Alexander Bukach notifications@github.com wrote:
@benjamin-dk should the link be sent to the client by the site, or should we only expose it to the counselor who will send it to the user? If the former, the counselor should indicate the email of the user, right?
-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cfdp/opeka/issues/92#issuecomment-305910107
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Sorry misread your question. The email is sent by the counsellor via his own mail client meaning it is NOT necessary to indicate client email.
On June 3, 2017 10:10:03 AM GMT+02:00, Benjamin Christensen notifications@github.com wrote:
It is sent by the counselor so yes the email should be indicated.
On June 2, 2017 11:10:45 PM GMT+02:00, Alexander Bukach notifications@github.com wrote:
@benjamin-dk should the link be sent to the client by the site, or should we only expose it to the counselor who will send it to the user? If the former, the counselor should indicate the email of the user, right?
-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cfdp/opeka/issues/92#issuecomment-305910107
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/cfdp/opeka/issues/92#issuecomment-305959824
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
@benjamin-dk it means that we should show the invitation link to the counselor after an invitation has been created, right?
yes exactly
On June 3, 2017 2:08:10 PM GMT+02:00, Alexander Bukach notifications@github.com wrote:
@benjamin-dk it means that we should show the invitation link to the counselor after an invitation has been created, right?
-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/cfdp/opeka/issues/92#issuecomment-305971023
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
@benjamin-dk why do we need to store the date and time? Just for information, or should we use it somehow (e.g. not let joining the chat before this time)?
Also, should the max number of participants in the invitation rooms be hardcoded to 2 (or another number) or be configurable?
@alex-bukach the motivation for the date feature was mostly to help the user remembering the date by getting get the date established formally in the system.
It should probably also be part of the text that the counselor copies to the email to be sent to the user. It could look something like this:
Dear counselor, please copy and paste the text below and send it to the client via email:
Dear
, you are hereby invited to chat with counselor at the following time: Wednesday 21. march 2017, 14:30
Just click the link below at the given time.
<invitation link>
It should be possible to adjust the number of participants to more than 2.
@benjamin-dk Do we ask the counselor to copy-paste the text manually because this is the less complex solution? I'm thinking a mail from the site would be the more foolproof way to go.
@jonassindal I also thought initially to send the mail from the site.
@jonassindal I figured that the counselor and the client would have established contact via email before reaching the point of creating the invitation. The email invitation link would then be a natural part of that ongoing conversation and the client wouldn't have to consider an email from an unknown source (the chat domain). But in terms of automation and reducing human errors yes I see your point. Both solutions seem acceptable to me.
Good point @benjamin-dk. I like your focus on the client perspective - I tend to be wearing the counsellor hat these days. If the relation is already established, I think the client would feel more comfortable receiving a message from the site. Meanwhile, I'm thinking about the amount of human errors we've run into lately. So we are going for automation.
Do we need to worry about ending up in spamfilters?
We still need to take into consideration how to create a safe and comfortable user experience, so I would like for there to be a custom text field where the counsellor can write a personal message to go along with the link/invitation from the site.
Lastly we need a descriptive and recognisable subject line for the mail. I'm thinking: "Chat invitation from [counsellor name]" (in Danish).
@jonassindal @benjamin-dk we I proceed with the automatic emails (with the personal message and a counselor name), right?
Also, @benjamin-dk does the "secret" status of the invitation rooms relate to the "private" rooms and queues? That private rooms (when a room marked "for training"), could you please explain me how they are supposed to work? Do they work properly?
@alex-bukach Yes you can proceed with the automatic email sending.
The "private" room feature has not been tested for a long time, but it should provide the same kind of "secret" room that we are after. It was originally built for training purposes. As far as I remember the counselor would open a room, copy the URL and send the room link to another counselor (not logged in), he would then be acting as an anonymous client.
@cfdp I tried the "private" rooms, however they appear in the list of rooms as the usual rooms. If I use these "private" rooms for the invitations, I should hide them from the list as requested. Is it ok?
@alex-bukach yes, that sounds right.
/Ben
@cfdp one more question: we send a link to a user containing a token. When user clicks the link, he's redirected to the room (if the room already exists). If now a user sends the URL of the group (e.g. /opeka#rooms/1312a1c6-7506-42ad-b50e-72cff0b6492c
) to another user, should that another user be able to enter the room (if the room is not full yet)?
I think it is fine to let other users enter via the URL since it is unique and complex @alex-bukach
Ok @cfdp. Another question: should the invited user enter his nickname, age etc. before entering the room?
@alex-bukach yes.
The invitation links should not be deleted when used, but should change state (e.g. to inactive)
@cfdp do you mean if the link is used, it's state is changed to inactive, and the user should not be able to use it anymore? I think we should allow multiple usage of a link: suppose a user has closed a browser by mistake -- they should be able to re-join the chat. Anyway when a counselor closes the chat room, the invitee won't be able to join it.
It should be possible to delete an invitation link in case a session is cancelled. A message reflecting this should be shown to the user if clicking on the link.
I think we should better have "cancelled" state of an invitation, otherwise how do we know that the invitation has been deleted? Or is it ok to show "The invitation does not exist" alert in the case?
@cfdp should the admins see the private rooms in the rooms list?
@alex-bukach: I agree on both points: The user should be able to re-join a chat if the connection was lost or the browser closed. And a "cancelled" state for the invitation link makes sense.
Finally - yes - the admins should be able to see the rooms, good point.
@cfdp when a counselor cancels an invitation:
@alex-bukach yes to the first question.
I don't think we should allow for re-activation. In that case, we might as well implement full CRUD (create, read, update, delete) functionality which I think is a bit much for now.
@cfdp @benjamin-dk finally done. See https://github.com/cfdp/opeka/pull/95/files?w=1 and https://github.com/cfdp/cura-chat-theme/pull/1/files?w=1.
To enable the feature just enable opeka_invite
module.
The configuration for email content is at /admin/config/services/opeka/invite, the list of all invitations is at /admin/reports/opeka-invites.
Once the module is enabled, a new button appears at the rooms page::
That button takes to the invitations page where one can create a new invitation and manage the existing ones (create/open a room for an invitation and cancel an invitation):
This differs a bit from the spec (e.g. new invitation button is not at the rooms page, but at this new invitations page), but it seems to have more sense for me to organize the things this way.
The emails are send via Drupal, so you might use e.g. Maillog module to test sending them.
@cfdp I have added a minor fix to the pull request, please make sure to pull the latest version for testing.
@alex-bukach I get the error
connect.js:4817 Uncaught TypeError: Cannot read property 'cancelled' of undefined
at child._computeChanges (backbone.js?ormwin:542)
at child.change (backbone.js?ormwin:478)
at child.set (backbone.js?ormwin:328)
at child.Backbone.Model (backbone.js?ormwin:242)
at new child (backbone.js?ormwin:1502)
at child._prepareModel (backbone.js?ormwin:900)
at child.add (backbone.js?ormwin:632)
at opeka.common.js?ormwin:245
at Proto.apply (connect.js:6071)
at Proto.handle (connect.js:6047)
Steps to repeat:
The anonymous user get the "Chat is cancelled" window when trying to log in to the chat.
@cfdp @benjamin-dk fixed.
@alex-bukach I get an "Email could not be sent" error from Drupal when cancelling an invite.
In the watchdog it looks like this (translated by hand from danish)
Location https://dev.demo/admin/opeka/invite/cancel/ajax
.......
Message Error when sending e-mail (from benjamin@greenvolcano.dk to <>).
Another thing:
In the specs we suggest to delete the invitation from the list when the corresponding room is deleted.
As far as I can see this is not implemented, correct? I think it will be necessary with a way of cleaning out old invitations so they don't end up with a long list of used invitations.
Maybe the better way would be to allow for invitations to be cancelled without sending automatic emails to the client?
@cfdp "Email could not be sent" is related to the server/Drupal settings, but not to Opeka code. Try sending reset password link to yourself on your test server and see whether it's sent successfully. BTW did it send the invitation link properly?
Re deleting the invitation I thought we agreed it was not required: e.g. when a counselor closes a tab by mistake, looses internet connection or like, now he's able to reopen the invitation room. I'd propose to delete the invitations (both active and invited) after some fixed time (like 24 hours, it will be configurable) after the scheduled time. Does it sound reasonable?
@alex-bukach the fixed time deletion solution sounds good.
About the cancelled invitattion email not being sent - yes the invitation link is sent just fine, so it seems counter intuitive that it should be a Drupal / server issue.
Right @cfdp, that's why I asked. I have pushed the fix for deletion.
As for deleting the old invitations, do you think we should display only cancelled invitations or all old ones?
@benjamin-dk I have just added cleanup feature to https://github.com/cfdp/opeka/pull/95.
There's a new input at the very bottom of /admin/config/services/opeka/invite form to set the expiration period. Once it's set, the app will delete the expired invites form both database and back/front-end each 30 minutes.
Feature finished in 20ec26a
Certain counseling scenarios call for the option of sending out a chat invitation link via email to clients.
In this way counselor and client can make an agreement on a scheduled date that suits both parties.
All that the client needs to do is to click the link at the provided time.
The counselor should then be ready in a chat room waiting to provide chat counseling.
Here are some criteria that should be met:
Added 9th of june: The counselors will probably need a way to access and alter existing invitation links, so we propose the following changes: