adding humans to the data

[tmyersdn]

This is from #245 (original comment below)

As we are currently testing/ using Bauble in a single user environment in SQLite, we don't have the complexity of dealing with a multiuser environment. But this does not mean we should not record staff involved with changing records. @RoDuth, if you go on leave for 6 months, or find a volunteer to help with data entry, would you not be keen to see some indication of who did the data entry when you get back to it (this has certainly saved my bacon on a regular basis here). I guess I am talking about a pseudo-multiuser environment, where a user would sign in, and their name would go against the history.

===original comment=== 7) "danger zone" - [...] this tool would be restricted to a few trained people.

you mean you would expect Bauble to restrict use to specific users? this is not implemented and not really available with sqlite (no user management).

if you do use a real database (other than sqlite), then users need log in and I could hide the whole danger zone. but still it's not implemented yet.

or you just tell "normal" users please to stay away from the danger zones.

[RoDuth]

I do get the user in my history table (user column in the :history view - or what I used to look at in SQLite Database Browser), well the user that was logged in at the time... at least I used to but it seems that since I have been using it on my home computer I dont?? curious, not really sure what to make of that. @mfrasca? And yes, I have used it. Also, it's not that hard to get a PostgreSQL set-up going (hell if I can do it locally... :smile: !!) so I don't think the average IT department would have too much issue with it and then you do get the log-in, user accounts with passwords etc. and the "users" item in the tools menu where you can set permissions etc.. (although, from memory, user permission control is not comprehensive at this point)

[mfrasca]

@RoDuth can you confirm you are using PostgreSQL also at home? and you are not seeing the user? anyhow, it's not nice that the user is not shown when the database is SQLite either. I would not know on Windows, but on unix (Linux&MacOSX) we always have the login name that we can use as user signing history data so regardless all other considerations we should have this info in the history.

[RoDuth]

I use SQLite at home and work. I have played with PostgreSQL at home but I managed to break it mucking around with importing data etc. haven't got back to fixing it yet. So in other words... the login name does appear in the :history view in the SQLite data I have from work (still on v1.0.11 Bauble on a windows set up), just I have an anomaly in that any changes I have made to it since I brought the SQLite file home to my Linux (Ubuntu 14.04) laptop have blanks in the login name column. I would need to qualify that in terms of accuracy (it looks about right at first glance but I haven't confirmed the dates against when I brought the data home). make any sense to you?

[mfrasca]

it might well be, I will check. thanks for the info.

[mfrasca]

curious, the code I had to correct was there unaltered since 2009, maybe engine.name changed since SQLAlchemy 0.5? thanks for both for reporting.

[tmyersdn]

@mfrasca @RoDuth thanks Mario for this. The main issue I can see is that if Ross is using SQLite at work, and gets volunteers or staff to use his login, then if Bauble detects use of SQLite, it will record all changes as if they are made by Ross. My suggestion is to implement a user login, which is independent of, but could relate to Baubles user management. This puts the responsibility on the user to sign in. If you are happy for this (hah!), it could go on the home screen. Can you think of another way for Bauble to log that more than one user is making changes on a SQLite system? Also, apologies for posting on this closed topic, hope you see this :)

[mfrasca]

no need to apologize and you can reopen the issue if you think so.

gets volunteers or staff to use his login

I sincerely hope he does not do that! a user login is to allow one user to login.

((this reminds me of a process for improper coinage of low valued money at the Naples mint around 1620, when people working part time at the mint had their own tools with which to strike the coins. so when 1g coins were struck on ¾g or even ½g blanks, they accused the employee corresponding to the tool used in the mistake. he was acquitted because everybody was using any tool they found at hand. — you have it all: untraceable use of login, part time users, consequent impossibility to enforce quality check.))

my opinion is: we are coping with complex systems offering us user management. either in the form of system-login or database -login. I would not want to implement any form of bauble-login. just use what we already have.

[tmyersdn]

Thanks Mario, yes, that is the problem exactly. I guess this possibility is always present when someone is logged in. However, with SQLite, if a user wants to get a 2nd person to do some data entry, then if I understand correctly, they would need to change the institutional user name temporarily add the new name into the data. I think this is not so good, as it is awkward, and also I think it is better to manage a list of users and record metadata (eg role, user status, privileges). Yes, please can you reopen the issue, and hopefully we can get Ross to comment?

[mfrasca]

I do not know about Windows, but unix you open a terminal window, you give the command: ssh -CY <other-user>@0 bauble the system will ask you <other-user>'s password. and bauble goes open under a different login. @RoDuth is at the beach, isn't he! :shell: :whale:

[RoDuth]

@tmyersdn @mfrasca, from the beach... one eye on the waves one eye on github and with sand in my ears and salt water up my nose :ocean: :laughing: That's dedication for you! I think from my perspective this was what I was getting at in issue #167 People who enter data are normally logged in as themselves even though they may be on my terminal when they do so, so I need a global install, not just for logging but also convenience. On the occasions that I have a volunteer without a login I get them to use some else's login, someone who doesn't enter data into the system. (you didn't hear that @KeithB42 if your listening) That way its clear in the logs. (I do really need to see if I can get the volunteers a login though.) Another thing I can do with SQLite which isn't so easy otherwise is just copy the database to a different folder for a particular session and connect to it there. (I also use this as a kind of training ground for anyone who isn't familiar with Bauble to give them somewhere they can play to their hearts content without mucking up my data). I agree with @mfrasca, its a much neater solution to use the systems that are already there. I have a few systems at work which, even though I am logged in to the network ask me to give my username and password. I find this very clunky.
(@tmyersdn not sure what changing the institute data would do? not sure it would make any difference to the logs)
Switching users in our systems at work is as quick as the three finger salute (ctrl-alt-del) selecting "switch user" and logging in. And if you have 2 people taking turns using the terminal its very easy to go back and forth between the 2.

@mfrasca

the code I had to correct was there unaltered since 2009, maybe engine.name changed since SQLAlchemy 0.5

that would explain it... the (very) old version at work must still be working! I'm glad it got picked up. When I get back from the sand and the surf I plan on upgrading at work so this is a fairly critical issue if I'm to do that. I'm also thinking of going the postgreSQL way which will make things a lot neater again in respect to users. ...anyway I'm of to frolic with the fishes :fish: :smile:

[tmyersdn]

thanks both of you