IRC logs of #tryton for Sunday, 2019-02-17 #tryton log beginning Sun Feb 17 00:00:01 CET 2019
-!- csotelo(~csotelo@ has joined #tryton00:02
-!- csotelo(~csotelo@ has joined #tryton00:02
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton01:02
-!- yangoon( has joined #tryton04:02
-!- jcm(~jcm@ has joined #tryton06:02
-!- thaneor1( has joined #tryton08:02
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton09:02
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.12:02
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.12:02
-!- csotelo(~csotelo@ has joined #tryton13:02
cedkrmu: precisely, you do not have to know the username13:02
cedkrmu: so if you add the username to the ID, it is no more posible to open URL to the right application13:02
cedkI'm still currious about the "valid case of mulitple user"13:02
rmucedk: but why do you know server/port/database and not username?13:02
cedkrmu: because username is not in the URL13:02
cedkand it would make URL pointless to put it as only the owner of the username will be able to open it13:02
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" cases13:02
cedkrmu: but it makes impossible to deduce the id13:02
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)13:02
semariebut I am fine with the current behaviour (even if there is few drawback)13:02
rmucedk: currently no id is included in the url, so the id is deduced (ask user to input user id)13:02
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)13:02
cedkrmu: I mean the application id13:02
cedkfor me, it is not enough common to have a special implementation13:02
rmuyes, it would probably confuse users13:02
cedkalso advanced user can use a workaround by using another OS user13:02
rmuother OS users is awkward13:02
rmuand not that easy in case of centralized user management (think AD or freeipa)14:02
cedkrmu: in such environment, you will not have multiple username on Tryton neither14:02
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.14:02
-!- irclog( has joined #tryton14:02
-!- nzaniela(~nzaniela@ has joined #tryton16:02
-!- nzaniela(~nzaniela@ has joined #tryton16:02
-!- sisalp( has joined #tryton17:02
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.17:02
sisalpWe can live without, but it was the main reason why I prefered tryton over sao.17:02
cedksisalp: there is the role module for that, you can plan and give access to another role for a period17:02
sisalpcedk: probably ok. nevertheless, activity will belong to me then. Will it fit for a backup ? I mean acting on behalf of some else ?17:02
cedksisalp: you do not act on behalf in this case but you are granted a role for a period18:02
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.18:02
-!- thaneor( has joined #tryton20:02
-!- semarie_(~semarie@unaffiliated/semarie) has joined #tryton22:02
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton23:02

Generated by 2.16.0 by Marius Gedminas - find it at!