On 28.7.2014 19:01, Endi Sukma Dewata wrote:
On 7/28/2014 6:06 AM, Petr Vobornik wrote:
Right now suppose I'm trying to delete a user, I have the delete dialog
open and I let it sit until the session expires, then when I click
Delete it will show me a login screen. Once I re-login, the dialog box
is gone. It still has the user to be deleted selected, but there's no
indication what the operation I was trying to do before.

I was thinking the session expiration would work like desktop
screensaver lock. So when I re-login I would see same screen as I left
it, i.e. the delete dialog is still waiting for action.

Components have not been made with this feature in mind. Take for
example the delete issue. Deleter dialog is a subclass of confirm
dialog. Confirm dialog is closed right after confirmation/cancellation.
It doesn't wait for the result of the operation because it's handled by
other components. The behavior was OK so far because we showed error
dialog on "normal" error. On auth error, the command was re-executed.
Now we don't show any error on auth error nor we leave the dialog open.
Seems like that we should change all usages of confirm dialog to try to
do the operation first and close the dialog after the operation was
successful or canceled.


Not sure about that. If you're adding a user that already exists, you'll
get an error dialog, but then if you click Cancel you'll go back to the
same add dialog.

Yes because the adder dialog remained opened (it was hidden while the error dialog was open because only one dialog can be visible at the same time).

That allows you to revise the info you entered. Can we
use the same concept for session expiration? So instead of an error
dialog you'll get a login screen. If you relogin as the same person,
you'll go back to the same dialog with whatever info you already entered.

I think we are in agreement. By the previous text I wanted to point out that not every component behaves as adder dialogs and that they should be identified and fixed. I.e. it's not just about session expiration.


This is a low priority regardless.



--
Petr Vobornik

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to