IRC logs of #tryton for Sunday, 2019-02-17 #tryton log beginning Sun Feb 17 00:00:01 CET 2019
-!- csotelo(~csotelo@ has joined #tryton23:37
-!- csotelo(~csotelo@ has joined #tryton23:44
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton00:50
-!- yangoon( has joined #tryton03:08
-!- jcm(~jcm@ has joined #tryton05:36
-!- thaneor1( has joined #tryton07:44
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton08:40
rmuregarding the unique client, what i find strange and arbitrary is that hostname/port/database is included in the instance id hash, but not the user id. IMO there are valid use-cases that require multiple connections from one desktop to the same server/database under different usernames.11:49
rmuregarding IPC, you already have to know server/port/database in order to identify the proper tryton client, in this case you probably also (can) know the username.11:50
-!- csotelo(~csotelo@ has joined #tryton12:18
cedkrmu: precisely, you do not have to know the username12:32
cedkrmu: so if you add the username to the ID, it is no more posible to open URL to the right application12:32
cedkI'm still currious about the "valid case of mulitple user"12:33
rmucedk: but why do you know server/port/database and not username?12:40
cedkrmu: because username is not in the URL12:41
cedkand it would make URL pointless to put it as only the owner of the username will be able to open it12:41
rmuyou can include usernames in URLs at a well-known place, the application can decide what to do with it and deal with the "no username" and the "username" cases12:48
cedkrmu: but it makes impossible to deduce the id12:49
semariecedk: I hitted the problem once, when I wanted to do quick configuration stuff without closing my running session (my user doesn't have adminsitration privilegies as it is special thing)12:49
semariebut I am fine with the current behaviour (even if there is few drawback)12:50
rmucedk: currently no id is included in the url, so the id is deduced (ask user to input user id)12:51
rmui'm also fine (also it is easy enough to workaround with SAO or a small patch that adds a command line argument to tryton to include user id in app id hash)12:52
cedkrmu: I mean the application id12:53
cedkfor me, it is not enough common to have a special implementation12:57
rmuyes, it would probably confuse users12:57
cedkalso advanced user can use a workaround by using another OS user12:58
rmuother OS users is awkward12:59
rmuand not that easy in case of centralized user management (think AD or freeipa)13:00
cedkrmu: in such environment, you will not have multiple username on Tryton neither13:01
rmuI think you are assuming too much. But it is kind of moot to discuss hypotheticals, if the requirement arises in the real world I'm sure there will be a solution.13:06
-!- irclog( has joined #tryton13:21
-!- nzaniela(~nzaniela@ has joined #tryton15:17
-!- nzaniela(~nzaniela@ has joined #tryton15:40
-!- sisalp( has joined #tryton16:07
sisalprmu: my use case so far was to backup people when they are off. For example, the assistant is off for a week, then I can open two tryton clients, one for me, one as a backup of the assistant.16:53
sisalpWe can live without, but it was the main reason why I prefered tryton over sao.16:55
cedksisalp: there is the role module for that, you can plan and give access to another role for a period16:57
sisalpcedk: probably ok. nevertheless, activity will belong to me then. Will it fit for a backup ? I mean acting on behalf of some else ?16:59
cedksisalp: you do not act on behalf in this case but you are granted a role for a period17:28
sisalpcedk:  when the assistant will be back, will he know what has been done while he was off ? Seen from the outside, the absence of the assistance should not be noticed because he is backuped by a colleague. Multi connections was not fully correct either.17:36
-!- thaneor( has joined #tryton19:46
-!- semarie_(~semarie@unaffiliated/semarie) has joined #tryton21:00
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton22:51

Generated by 2.17.3 by Marius Gedminas - find it at!