Authorization: automatic refusal

Do you think that is user friendly?
It will depend on the user sitting staring on the machine and hit a button
just at the right time. Seems a bit stressing to me.
CC to Sander for opinion.
Perhaps it could be added as a config() option?

Zbiggy:

> Do you think that is user friendly?

Yes. I don't have to refuse authorization on my own - which can lead to
misunderstandings - while keeping the possibility to authorize selected
persons.

> It will depend on the user sitting staring on the machine and hit a button
> just at the right time. Seems a bit stressing to me.

Why? Currently you have no such oportunity. It doesn't change anything -
it adds new possibility.

> CC to Sander for opinion.
> Perhaps it could be added as a config() option?

If you like...

Sander:

I think it is better then to add an option in the preferences that
automatically rejects all subscription requests when the user is
away/extended away (and maybe also busy?). If the user enables this
option in the config he can enter in a field a message that will be
sent to the contact. As this can be a privacy issue, this option
should not be enabled by default.

So:
Checkbox option: Always reject when away (and busy?)
Text field: "I am currently not able to review your subscription
request. Please try to add me to your list later."

Though, I did not see that good why such an option can be useful. Can
you explain *why* a user would want this option in the first place? A
(few) good use case(s) can be convincing ;-)

I vote for Sander.
Although I'm afraid of the option proliferation. (Number of them goes to infty).

Sander:
2007/11/9, Zbigniew Baniewski < <email address hidden> >:
> On Fri, Nov 09, 2007 at 02:47:06PM +0100, Sander Devrieze wrote:
>
> > Though, I did not see that good why such an option can be useful. Can
> > you explain *why* a user would want this option in the first place? A
> > (few) good use case(s) can be convincing ;-)
>
> Just to avoid misunderstandigs.
>
> Picture some situation: your customer wants to talk with you, and sends an
> authorization request - just because of his habit, perhaps he even really
> actually doesn't need. You'll not authorize him - he can think: "he
> refused - what an arrogant person". You'll gave him the authorization - he
> can bother you then everytime, when he sees your contact "on" - which not
> always can be desired. Yes, you can then use "privacy list", and keep the
> contact, which (probably) you won't need anymore, or withdraw
> authorization, with the same effect, as described on the beginning. Better
> is to use "automatic refusal" - but sometimes there's indeed a need to
> authorize someone - so switching that option in setup is a bit inconvenient.
>
> Currently Coccinella has "automatic refusal", which makes it easier, just
> because "it wasn't me; it's automatic". And because of this two supplemental
> features could make this option complete: 1) A message, sent with refusal,
> and explaining "rejected automatically" (perhaps a bit more specific), and
> 2) Showing that window with a button "authorize" to click onto during 5
> seconds delay, when I can authorize someone anyway, if I "really really"
> want to. Such option won't interfere with anything. It'll appear - and
> disappear in 5 seconds. What's the problem? I can't see a sense with that
> "X/A" - from my experience, most authorization requests are sent while I'm
> present. Although it could work in this way; I'm not opposed.

ok, ic. so you want an additional popup when automatic reject is
enabled (@Mats: text not optimal!):
"Subscription request of <contact> will be rejected in:
<counter:start=5> secs. If you don't do anything this dialog will be
closed and the request will be rejected. Click the following button to
accept this request anyway and cancel the rejection.
<button:Accept anyway>

And maybe something similar for auto-accept?

> My quite personal opinion is, that the Jabber authorization system neither
> is especially useful, nor actually there isn't any need for such feature.

It's added for privacy reasons AFAIK. Ask stpeter for more details :-)

> Anyway: if you want to reach someone by the phone, you're just calling him,
> although you don't know his/her actual "presence". If he's near the phone,
> and wants to talk with you - he'll answer. If he doesn't want to chat with
> you - what's the use in knowing his status? And, at last, if he isn't
> currently logged in - will answer later.

Well, the idea behind presence is that the one who contacts you can
decide if he really needs to contact you. If you are busy, he may want
to contact someone else or he may contact you later. But if it is
really important, he can decide to contact you anyway. So, the one who
contacts you knows before...

Sander:
2007/11/9, Zbigniew Baniewski < <email address hidden> >:
> On Fri, Nov 09, 2007 at 10:15:00PM +0100, Sander Devrieze wrote:
>
> > ok, ic. so you want an additional popup when automatic reject is
> > enabled (@Mats: text not optimal!):
> > "Subscription request of <contact> will be rejected in:
> > <counter:start=5> secs. If you don't do anything this dialog will be
> > closed and the request will be rejected. Click the following button to
> > accept this request anyway and cancel the rejection.
> > <button:Accept anyway>
> >
> > And maybe something similar for auto-accept?
>
> Maybe good idea - it would be symmetric in such way.

CC'ed to Mats.

> > > My quite personal opinion is, that the Jabber authorization system neither
> > > is especially useful, nor actually there isn't any need for such feature.
> >
> > It's added for privacy reasons AFAIK. Ask stpeter for more details :-)
>
> You know: I understand the intentions - but I tried to diagnose the reality.
>
> > > Anyway: if you want to reach someone by the phone, you're just calling him,
> > > although you don't know his/her actual "presence". If he's near the phone,
> > > and wants to talk with you - he'll answer. If he doesn't want to chat with
> > > you - what's the use in knowing his status? And, at last, if he isn't
> > > currently logged in - will answer later.
> >
> > Well, the idea behind presence is that the one who contacts you can
> > decide if he really needs to contact you. If you are busy, he may want
> > to contact someone else or he may contact you later. But if it is
> > really important, he can decide to contact you anyway. So, the one who
> > contacts you knows before doing that how much time you have to help
> > him. This is a big advantage over telephone.
>
> I wrote the above after the observation of several users of our polish IM
> service, "Gadu-Gadu". Most (OK, not everybody, anyway...) of users are
> switching their status just to "invisible", in such way ignoring the entire
> status reporting system - and this is the simplest way to protect your
> privacy. No need for any "privacy lists", JEP-s, RFC-s...

If I am right, the privacy XEP is obsolete now in favour of privacy
lists (aka communication blocking). Note that privacy lists also allow
other things like dropping messages from contacts without them knowing
it. Not yet supported by Coccinella though...all just some information
:-)

> GG's status
> system has less "levels", than the jabberish

XMPP is eXtensible; it has lot's of "levels" but that doesn't mean you
need to implement them all for the average stupid user. See also
Google Talk for another example ;-)

> - but I noticed, that since
> some time Mats reduced the levels in that rapidly-reachable menu bottom
> left... so, it seems, that most of Coccinella (or even just Jabber-users)
> doesn't need so sophisticated system, preferring simplicity.

Well, there still is the Custom presence state in which the user can
select another state (and message) which is then remembered as recent
state.

Jabber system requires authorization, which not always is desired by *BOTH* parties simultaneously. In such situations, Coccinella's feature "automatic refusal/acceptance" is very handy - but using it, one has to rely completely on that automatic handling of requests - or has to constantly switch the option from automatic to manual (then restart client...) and back.

To make this automatic handling complete, my suggestion was to:

- add additional notification window, which could give 5 second time to take a decision, does one want to authorize the caller anyway

- if no action in such window from callees side will be taken: it refuses to give
authorization then, but sending simultaneously a message, like f.e. "Your request has been automatically refused by the peers IM client software. It wasn't an action taken by your party"

In my opinion, it's not very necessary to add this as another option in "Preferences". The proposed window will disappear in 5 seconds, so it'll not spoil anything, neither won't be disturbing the user too much. It can be even solved in other way: f.e. flashing caller's contact could arrive on the roster for that 5 seconds, and clicking on it will mean "authorize him" - or in similar way.

Sander's suggestion to introduce something "symmetrical" for the option "automatic acceptance" (in this case clicking will mean: "reject this request") could make both options even more complete.

There are now some code that supports this but nothing activated and not tested! To be continued...

Now some more support for this which is almost untested so far. I haven't switched it on by default in cvs in order not to screw up the current build efforts. Please find in jabber/Jabber.tcl and Subscribe.tcl:

     # Set a timer dialog instead of just straight auto rejecting.
    set ::config(subscribe,auto-reject-timer) 0

     # Set a timer dialog instead of just straight auto accepting.
    set ::config(subscribe,auto-accept-timer) 0

    # Shall we send a message to user when one of the auto dispatchers done.
    set ::config(subscribe,auto-reject-send-msg) 0
    set ::config(subscribe,auto-accept-send-msg) 0
...

    # Sets the number of millisecs the dialog starts its countdown.
    set ::config(subscribe,accept-after) 10000
    set ::config(subscribe,reject-after) 10000

The logic is likely not right, but feedback wanted of how the exact behavior shall be.
You can experiment yourself with the code in Subscribe.tcl

bug (in auto-reject AFAIR):

can't read "from": no such variable
can't read "from": no such variable
    while executing
"SendAutoRejectMsg $from"
    (procedure "RejectCmd" line 7)
    invoked from within
"RejectCmd Jabber@ID ._ui_dlg077165ba reject"
    (in namespace inscope "::Subscribe" script line 1)
    invoked from within
"::namespace inscope ::Subscribe {RejectCmd Jabber@ID} ._ui_dlg077165ba reject"
    invoked from within
"catch [linsert $options(-command) end $win $button] result"
    invoked from within
"::ui::dialog::widget::Snit_methodDone ::ui::dialog::widget ::ui::dialog::widget::Snit_inst8 ._ui_dlg077165ba ._ui_dlg077165ba reject"
    ("uplevel" body line 1)
    invoked from within
"uplevel 1 $command $args"
    invoked from within
"._ui_dlg077165ba Done reject"
    invoked from within
"._ui_dlg077165ba.f.b.reject invoke "
    invoked from within
"._ui_dlg077165ba.f.b.reject instate {pressed !disabled} { ._ui_dlg077165ba.f.b.reject state !pressed; ._ui_dlg077165ba.f.b.reject invoke } "
    (command bound to event)

Feature wishes:
* Add "Pause" button
* Use the same dialog as when the user selects "Always ask", but grey out all fields and buttons etc besides Yes, No, and Pause. If people click on Pause, the greyed out things should become active again.
* Allow end users to enter the time value in the preferences. If they enter 0 (zero), the dialog and counter is disabled and the user will have the old behaviour of these options.
* Add an additional option in the prefs (be default enabled): "Disable counter when Away or Extended Away"
* Make this the default: Auto-accept with 10 secs (or more?).
* Add support for multiple semi-simultaneous subscription requests (like you implemented recently for "Always ask"). Also grey out the submenus and add a pause button. btw: Can you also add a way to view the business card in all submenus. Maybe you can use an icon with balloon text like I already suggested (also see Psi). Also use this icon in the single subscription request dialog (and remove the big button there).
* jamesssubscautoacc: In %s seconds, the computer will answer "Yes" to next question:\n<bold>May %s see your presence?</bold>\nYou still can select another answer.
* jamesssubscautorej: In %s seconds, the computer will answer "No" to next question:\n<bold>May %s see your presence?</bold>\nYou still can select another answer.
* in the above 2 strings you can reduce the work for translators by using the append feature for the last 2 sentences (one of them is already in 0.96.2)!!

Bug fixed. Was also in auto accept.

Also, added support for user config file as (resources/README-config):

At the bottom there are hardcoded options stored in the global 'config'
array. These defaults are set within in each package that uses them.
They can be overriden by any resources/config.tcl file. Normally there
is no such file, but it can be put there at build time. This allows for
custom builds that change "lower-level" details of how the application
works and looks.

It is also possible for a user to put such a file in the preference folder as:
    Coccinella/resources/config.tcl
which will override any hardcoded or build configs.

I don't get what you are aiming at:

* Use the same dialog as when the user selects "Always ask", but grey out all fields and buttons etc besides Yes, No, and Pause. If people click on Pause, the greyed out things should become active again.

* jamesssubscautoacc: In %s seconds, the computer will answer "Yes" to next question:\n<bold>May %s see your presence?</bold>\nYou still can select another answer.

Do you want the jamesssubscautoacc string to be appended to the ::Subscribe::NewDlg dialog, and ::SubscribeEx::NewDlg?

Pause button doesn't fit since the "View Business Card..." takes too much space.

2007/11/13, Mats <email address hidden>:
> I don't get what you are aiming at:
>
> * Use the same dialog as when the user selects "Always ask", but grey
> out all fields and buttons etc besides Yes, No, and Pause. If people
> click on Pause, the greyed out things should become active again.

I mean: use a similar dialog as when the user has selected "Always
Ask" as action for presence subscription requests.

> * jamesssubscautoacc: In %s seconds, the computer will answer "Yes" to
> next question:\n<bold>May %s see your presence?</bold>\nYou still can
> select another answer.
>
> Do you want the jamesssubscautoacc string to be appended to the
> ::Subscribe::NewDlg dialog, and ::SubscribeEx::NewDlg?

??? I just mean "May %s see your presence?" and "You still can
> select another answer." should be separate strings.

> Pause button doesn't fit since the "View Business Card..." takes too
> much space.

That's why this button should be replaced by an icon button next to
one of the text fields in the dialog.

--
Mvg, Sander Devrieze.

I'm still skeptical about this. Anyhow, a screenshot can be obtained by:

::Subscribe::NewDlg <email address hidden> -auto accept

There are just too much info to be able to congest it.

???

2007/11/13, Mats <email address hidden>:
> I'm still skeptical about this. Anyhow, a screenshot can be obtained by:
>
> ::Subscribe::NewDlg <email address hidden> -auto accept
>
> There are just too much info to be able to congest it.
>
> --
> Authorization: automatic refusal
> https://bugs.launchpad.net/bugs/161203
> You received this bug notification because you are a member of
> Coccinella, which is the bug contact for Coccinella.
>
>

--
Mvg, Sander Devrieze.

There are now so many execution paths I get completely lost :-)
Anyway, I need constant feedback during this process so I don't implement something which is not wanted. From the console, do:
::Subscribe::NewDlg xxxxx@yyyyy -auto accept
::Subscribe::NewDlg xxxxx@yyyyy -auto reject
just for testing. Do it offline since it is just a fake.

Splitting up a line as in:
* jamesssubscautoacc: In %s seconds, the computer will answer "Yes" to next question:\n<bold>May %s see your presence?</bold>\nYou still can select another answer.
is technically very difficult, and impossible in the message box I use. I can use the text without bold or nowlines, however.

configs so far:

    # Set a timer dialog instead of just straight auto accepting.
    set ::config(subscribe,auto-accept-timer) 0

    # Sets a timer in the standard "ask" dialogs to auto accept.
    set ::config(subscribe,auto-accept-std-dlg) 0

    # Set a timer dialog instead of just straight auto rejecting.
    set ::config(subscribe,auto-reject-timer) 0

    # Sets a timer in the standard "ask" dialogs to auto accept.
    set ::config(subscribe,auto-reject-std-dlg) 0

    # Shall we send a message to user when one of the auto dispatchers done.
    set ::config(subscribe,auto-accept-send-msg) 0
    set ::config(subscribe,auto-reject-send-msg) 0

    # Millis to wait for a second subsciption request to show in multi dialog.
    set ::config(subscribe,multi-wait-ms) 2000

    # Use the multi dialog for batches of subscription requests.
    set ::config(subscribe,multi-dlg) 1

    # Sets the number of millisecs the dialog starts its countdown.
    set ::config(subscribe,accept-after) 10000
    set ::config(subscribe,reject-after) 10000

    # Millis to wait for a second subsciption request to show in multi dialog.
    set ::config(subscribed,multi-wait-ms) 4000

    # Use the multi dialog for batches of subscription requests.
    set ::config(subscribed,multi-dlg) 1

    # Use a fancy dialog for queued 'subscribed' events.
    set ::config(subscribed,fancy-dlg) 1

You see. Many execution paths it is...

2007/11/14, Mats <email address hidden>:
> There are now so many execution paths I get completely lost :-)

I don't think you need to make different dialogs (like the current
situation). I guess you can re-use many parts of the UI.

> Anyway, I need constant feedback during this process so I don't implement something which is not wanted. From the console, do:
> ::Subscribe::NewDlg xxxxx@yyyyy -auto accept
> ::Subscribe::NewDlg xxxxx@yyyyy -auto reject
> just for testing. Do it offline since it is just a fake.

Problem is I'm currently in my "Mac OS X" days and I was not yet able
to start Coccinella from the console on Mac OS X. Ask me again in a
couple of days or let me test other things ;-)

> Splitting up a line as in:
> * jamesssubscautoacc: In %s seconds, the computer will answer "Yes" to next question:\n<bold>May %s see your presence?</bold>\nYou still can select another answer.
> is technically very difficult, and impossible in the message box I use. I can use the text without bold or nowlines, however.

We already did something like this for other strings...so??

> configs so far:
>
> # Set a timer dialog instead of just straight auto accepting.
> set ::config(subscribe,auto-accept-timer) 0

Not necessary, you can simulate this using the "Sets the number of
millisecs the dialog starts its countdown." option by entering 0.

> # Sets a timer in the standard "ask" dialogs to auto accept.
> set ::config(subscribe,auto-accept-std-dlg) 0

Is this useful?

> # Set a timer dialog instead of just straight auto rejecting.
> set ::config(subscribe,auto-reject-timer) 0

Not necessary, you can simulate this using the "Sets the number of
millisecs the dialog starts its countdown." option by entering 0.

> # Sets a timer in the standard "ask" dialogs to auto accept.
> set ::config(subscribe,auto-reject-std-dlg) 0

Is this useful? (btw: it should be auto reject instead of accept)

--
Mvg, Sander Devrieze.

On 11/14/07, sander <email address hidden> wrote:
> 2007/11/14, Mats <email address hidden>:
> > There are now so many execution paths I get completely lost :-)
>
> I don't think you need to make different dialogs (like the current
> situation). I guess you can re-use many parts of the UI.
>
> > Anyway, I need constant feedback during this process so I don't implement
> something which is not wanted. From the console, do:
> > ::Subscribe::NewDlg xxxxx@yyyyy -auto accept
> > ::Subscribe::NewDlg xxxxx@yyyyy -auto reject
> > just for testing. Do it offline since it is just a fake.
>
> Problem is I'm currently in my "Mac OS X" days and I was not yet able
> to start Coccinella from the console on Mac OS X. Ask me again in a
> couple of days or let me test other things ;-)

Just do menu Info/Debug and up comes the console.
There you enter tcl code as you did in Terminal.

>
> > Splitting up a line as in:
> > * jamesssubscautoacc: In %s seconds, the computer will answer "Yes" to
> next question:\n<bold>May %s see your presence?</bold>\nYou still can select
> another answer.
> > is technically very difficult, and impossible in the message box I use. I
> can use the text without bold or nowlines, however.
>
> We already did something like this for other strings...so??

???

>
> > configs so far:
> >
> > # Set a timer dialog instead of just straight auto accepting.
> > set ::config(subscribe,auto-accept-timer) 0
>
> Not necessary, you can simulate this using the "Sets the number of
> millisecs the dialog starts its countdown." option by entering 0.

It is good practice to have very explicit settings/code as possible.

>
> > # Sets a timer in the standard "ask" dialogs to auto accept.
> > set ::config(subscribe,auto-accept-std-dlg) 0
>
> Is this useful?

That's what I thought you wanted. See for yourself:
::Subscribe::NewDlg junk -auto accept

>
> > # Set a timer dialog instead of just straight auto rejecting.
> > set ::config(subscribe,auto-reject-timer) 0
>
> Not necessary, you can simulate this using the "Sets the number of
> millisecs the dialog starts its countdown." option by entering 0.

See above

>
> > # Sets a timer in the standard "ask" dialogs to auto accept.
> > set ::config(subscribe,auto-reject-std-dlg) 0
>
> Is this useful? (btw: it should be auto reject instead of accept)
>

Typo. See above.

Should be there now.