Set owner/multi-user #42

New Issue

FrederikBaerentsen · 2025-01-19T11:41:14+01:00

2025-01-19 11:41:14 +01:00

...to me, just being able to "tag" each set (both owned and on wishlist) with a name, that can then be used in a filter, would be enough "multi-user support".
I'd much rather keep it in one container, so I have the full overview of everything we own in our family, than splitting it up.
But of course, this could be different for different users.

_Originally posted by jonaskp86 (assuming @jonaskp) in https://old.reddit.com/r/selfhosted/comments/1hmx314/bricktracker_a_selfhosted_web_app_for_tracking/m3zd1kt/

I kinda like this idea. Currently I'm running three instances (myself, my wife and my son) but it would greatly improve our workflow with just one database.

Add field to database table. Ensure it doesn't break existing table.
Add env option:

# Optional: Show field for user/owner.
# Default: false
# BK_USER_TAG=true

# Optional: List of users to select from
# Required if BK_USER_TAG=true
# BK_USER_LIST=person1, person2, person3

Add dropdown on /add and /add/bulk) to select owner of the set.
Add dropdown on /sets/*/details to show and edit the data.

> ...to me, just being able to "tag" each set (both owned and on wishlist) with a name, that can then be used in a filter, would be enough "multi-user support". I'd much rather keep it in one container, so I have the full overview of everything we own in our family, than splitting it up. But of course, this could be different for different users. _Originally posted by jonaskp86 (assuming @jonaskp) in https://old.reddit.com/r/selfhosted/comments/1hmx314/bricktracker_a_selfhosted_web_app_for_tracking/m3zd1kt/ I kinda like this idea. Currently I'm running three instances (myself, my wife and my son) but it would greatly improve our workflow with just one database. - [ ] Add field to database table. Ensure it doesn't break existing table. - [ ] Add env option: ````bash # Optional: Show field for user/owner. # Default: false # BK_USER_TAG=true # Optional: List of users to select from # Required if BK_USER_TAG=true # BK_USER_LIST=person1, person2, person3 ```` - [ ] Add dropdown on `/add` and `/add/bulk`) to select owner of the set. - [ ] Add dropdown on `/sets/*/details` to show and edit the data.

👍 1

FrederikBaerentsen added the

Kind/Feature

label 2025-01-19 11:41:14 +01:00

FrederikBaerentsen added this to the General Improvements project 2025-01-19 11:41:14 +01:00

jonaskp commented

2025-01-19 11:56:33 +01:00

Assumption correct :-)

Just thinking, Probably need to include handling of “joint ownership” sets, most easily by allowing “owner” to be blank I assume.

This is not something I have experienced yet, as my wife is very protective of her Creator Icons buildings, and doesn’t Care for any of my Old Technic stuff :-D

But I am sure lots of people would buy sets together, and then it would be Nice to have some sort of option for it.

Assumption correct :-) Just thinking, Probably need to include handling of “joint ownership” sets, most easily by allowing “owner” to be blank I assume. This is not something I have experienced yet, as my wife is very protective of her Creator Icons buildings, and doesn’t Care for any of my Old Technic stuff :-D But I am sure lots of people would buy sets together, and then it would be Nice to have some sort of option for it.

FrederikBaerentsen commented

2025-01-19 12:52:19 +01:00

I see what you mean. I haven't had the issue myself either, but having the option to leave it blank might be good.

gregoo commented

2025-01-19 13:07:35 +01:00

On a side note: This would probably require a proper migration of the database as there are many things wrong that make the code more complex than it should be (tell me about it 🙃).
The tables are missing primary keys, indexes, and the column name are less than explicit and there is a lot of duplicated data in the database. (Same remark for #41)

On a side note: This would probably require a proper migration of the database as there are many things wrong that make the code more complex than it should be (tell me about it 🙃). The tables are missing primary keys, indexes, and the column name are less than explicit and there is a lot of duplicated data in the database. (Same remark for #41)

FrederikBaerentsen commented

2025-01-19 13:44:44 +01:00

Alright, I’ll definitely have to read through the sql changes and see about migration to new schema.

I’m by no means an sql expert and figured I had covered most in the initial setup 😁

Alright, I’ll definitely have to read through the sql changes and see about migration to new schema. I’m by no means an sql expert and figured I had covered most in the initial setup 😁

gregoo commented

2025-01-19 13:51:15 +01:00

I made no change to your database structure (https://gitea.baerentsen.space/FrederikBaerentsen/BrickTracker/src/branch/master/bricktracker/sql/migrations/init.sql). I merely worked around it to the best I could. As you can see there is only this file in the migrations folder.

I moved the queries into SQL files but then again, still based on your initial structure. I wanted it to be a drop-in replacement for your original version.

A framework like django has all the database migration baked-in, but since this is using flask it is a bit more bare-bones (which is not necessarily a bad thing). With flask and sqlite you can bake in a forward-only lightweight migration system but that will take a bit of code, and some advanced knowledge of SQL.

Remember, that at the beginning:

I wanted to add some features that would be useful to me (like who owns the set, where it is stored)

#8 (comment)

I haven't even done that 🙃

I made no change to your database structure (https://gitea.baerentsen.space/FrederikBaerentsen/BrickTracker/src/branch/master/bricktracker/sql/migrations/init.sql). I merely worked around it to the best I could. As you can see there is only this file in the `migrations` folder. I moved the queries into SQL files but then again, still based on your initial structure. I wanted it to be a drop-in replacement for your original version. A framework like `django` has all the database migration baked-in, but since this is using `flask` it is a bit more bare-bones (which is not necessarily a bad thing). With `flask` and `sqlite` you can bake in a forward-only lightweight migration system but that will take a bit of code, and some advanced knowledge of SQL. Remember, that at the beginning: > I wanted to add some features that would be useful to me (like who owns the set, where it is stored) https://gitea.baerentsen.space/FrederikBaerentsen/BrickTracker/issues/8#issuecomment-154 I haven't even done that 🙃

gregoo commented

2025-01-20 11:18:44 +01:00

I'm testing how to do the SQL migration thingy

I'm testing how to do the SQL migration thingy ![image](/attachments/cdf76dee-302b-4d81-9292-84a3aa4f891d) ![image](/attachments/4d9b5281-18f2-43c6-a789-b0e06f99e596)

image.png

47 KiB

image.png

47 KiB

tapps commented

2025-01-20 12:05:30 +01:00

Just thinking, Probably need to include handling of “joint ownership” sets, most easily by allowing “owner” to be blank I assume.

Rather than owner being blank, could it support multiple owner tags? That would seem to make more sense if you're trying to filter or search by owners etc

> Just thinking, Probably need to include handling of “joint ownership” sets, most easily by allowing “owner” to be blank I assume. Rather than owner being blank, could it support multiple owner tags? That would seem to make more sense if you're trying to filter or search by owners etc

Sign in to join this conversation.