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

bitkraken commented

2025-01-28 14:12:34 +01:00

dumb question: currently there is already a custom field option for Checkboxes. could this may be enhanced to support other field types? free text, list choice (with single or multiple choice), ...

because what I see: there is currently a lot of new interst in BrickTracker (myself included), and many have some kind of special request, what they would like to track: owner, set condition, purchase location, purchased price, storage location, ...
with some more custom field types, many of those could be fulfilled at once. :)

dumb question: currently there is already a custom field option for Checkboxes. could this may be enhanced to support other field types? free text, list choice (with single or multiple choice), ... because what I see: there is currently a lot of new interst in BrickTracker (myself included), and many have some kind of special request, what they would like to track: owner, set condition, purchase location, purchased price, storage location, ... with some more custom field types, many of those could be fulfilled at once. :)

FrederikBaerentsen commented

2025-01-28 15:14:23 +01:00

@bitkraken The checkbox field is more of a "yes/no" and not a custom label. If you want an "owner" on the set, you would probably have:

Person A
Person B
Person C

Using the current checkbox method, you could add those but it would quickly take up a lot of space.

You could hide them on the main page, but I think what people would enjoy is something like this:

Where the "owner" is a badge.

I think a lot of into could go into the checkboxes though. I'm for example storing into about 'new/used' and 'build/unbuild' in checkboxes, but then hiding them on the main page.

See Checkbox docs for more info.

@bitkraken The checkbox field is more of a "yes/no" and not a custom label. If you want an "owner" on the set, you would probably have: - Person A - Person B - Person C Using the current checkbox method, you could add those but it would quickly take up a lot of space. ![](https://xbackbone.baerentsen.space/LaMU8/ruwIPuzu14.png/raw) You could hide them on the main page, but I think what people would enjoy is something like this: ![](https://xbackbone.baerentsen.space/LaMU8/DUnaLUfa96.png/raw) Where the "owner" is a badge. I think a lot of into could go into the checkboxes though. I'm for example storing into about 'new/used' and 'build/unbuild' in checkboxes, but then hiding them on the main page. See [Checkbox](src/branch/master/docs/checkbox.md) docs for more info.

bitkraken commented

2025-01-28 16:10:59 +01:00

hey @FrederikBaerentsen thanks for the quick reply. yes, I know about the current usage of the checkbox. my suggestion was to make new custom fields, that have other properties like "customField: freetext" or "customField: selection[A,B,C]".

But looks like the development for the owner badge is already coming together pretty good and I'm probably too late to the party 😆

hey @FrederikBaerentsen thanks for the quick reply. yes, I know about the current usage of the checkbox. my suggestion was to make new custom fields, that have other properties like "customField: freetext" or "customField: selection[A,B,C]". But looks like the development for the owner badge is already coming together pretty good and I'm probably too late to the party 😆

FrederikBaerentsen commented

2025-01-28 19:53:05 +01:00

This was just a mock-up and not actually implemented. But it was how I envisioned it could be implemented.

gregoo commented

2025-01-28 19:59:43 +01:00

I think you want too much out of how complex this application is willing to be (hint: not very complex as far as I'm concerned) 😂.
It's built on top of Flask and SQLite which is quite a nightmare it terms of evolving the database model.

I can't dive into the rabbit hole that are custom fields with special presentation as you suggest, that looks very complicated to produce. Also keep in mind that the application is veeeeeeeery static. Having so much data per object would require something more dynamically tied to the backend to make sense 🙂.

I think you want too much out of how complex this application is willing to be (hint: not very complex as far as I'm concerned) 😂. It's built on top of Flask and SQLite which is quite a nightmare it terms of evolving the database model. I can't dive into the rabbit hole that are custom fields with special presentation as you suggest, that looks very complicated to produce. Also keep in mind that the application is veeeeeeeery static. Having so much data per object would require something more dynamically tied to the backend to make sense 🙂.

gregoo commented

2025-01-30 18:44:01 +01:00

Frontpage mini

Set grid

Details

Set management

Admin owner management

🙂

- Frontpage mini ![image](/attachments/6b1480dc-472e-409b-b01e-e00767aaabf9) - Set grid ![image](/attachments/d7d6c7cc-d58d-440f-80a9-558d96002e20) - Details ![image](/attachments/21ea1b74-45fd-45b4-8d0b-9748bc46e18b) - Set management ![image](/attachments/0b835d97-6882-4d96-8d2c-4535dd1c4c21) - Admin owner management ![image](/attachments/80d01fc0-3e8f-4af8-9b2d-16f5c84aa357) 🙂

image.png

114 KiB

image.png

63 KiB

image.png

34 KiB

image.png

464 KiB

image.png

145 KiB

FrederikBaerentsen commented

2025-01-30 20:00:44 +01:00

That looks great!

gregoo commented

2025-01-31 10:57:23 +01:00

Reworked the grid controls to accomodate a new filter

Reworked the grid controls to accomodate a new filter ![image](/attachments/fcbffaab-99f3-447b-9147-7309426147b2)

image.png

159 KiB

gregoo commented

2025-01-31 11:08:00 +01:00

The owner name is available for the search

The owner name is available for the search ![image](/attachments/62acdf74-99a5-4419-8b8f-b7536d8f8ac5)

image.png

118 KiB

gregoo commented

2025-01-31 16:26:22 +01:00

Owners when adding

Owners when adding ![image](/attachments/498cf223-cb5b-423b-b1f7-88c1646cebfc) ![image](/attachments/d2150f82-9e38-44f6-b13e-6ba12521e16f)

image.png

49 KiB

image.png

406 KiB

gregoo commented

2025-02-04 20:01:18 +01:00

Lightweight "requesters" for wishes (it's quite crude I didn't bother too much, it uses the Set owners)

Wish requester (there's a new wish "details" page)

Table

Search

Lightweight "requesters" for wishes (it's quite crude I didn't bother too much, it uses the Set owners) - Wish requester (there's a new wish "details" page) ![image](/attachments/fd8599ed-8331-4f4c-834a-9dbf8e843728) - Table ![image](/attachments/f19a8f8d-12f7-4824-bee1-2cdc15567385) - Search ![image](/attachments/dbb00b27-0e62-4dcb-acb6-952d112809dc)

image.png

146 KiB

image.png

271 KiB

image.png

122 KiB

gregoo commented

2025-02-10 16:45:51 +01:00

Implemented in 1.2.0.
Should we open a separate issue to tracker @bitkraken request for custom fields?

Implemented in `1.2.0`. Should we open a separate issue to tracker @bitkraken request for custom fields?

Sign in to join this conversation.