Multi-User Photo Gallery with private and shared photos/albums
rkkoszewski opened this issue · comments
It would be great to be able to share a PhotoPrism server between several people, each having their own private pictures/albums, and pictures/albums that could be shared with other users on the same server.
This would probably increase the complexity of the project quite a bit as a whole session/login/profile system would need to be implemented and also handle how to manage the pictures (All pictures in a single folder and assigned to different users by Database, a special folder structure, etc), most likely not compatible with how it works now.
I was not able to find out from the Wiki about what kind depth is PhotoPrism aiming at regarding photo management. Any input on this from the Devs?
@rkkoszewski This is something we want to do, but also not for the start.
Related Gitter chat log for future reference:
Michael Mayer @lastzero 14:26
For multi user, we basically just need to add a users table to the db... what gets tricky are ACLs, roles and layered permissions - which is what people often mean with "multiple users". This won't be a free enterprise solution.
Ferdinand Mütsch @n1try 14:26
What I primarily meant by sharing is to have photo albums that are owned by multiple users (friends, family, ...) and are read + write for all of them. Probably a bigger feature
Michael Mayer @lastzero 14:27
I've done all of this for Deutsche Telekom ("Mediencenter") a couple of years ago, so I know what's needed.
Ferdinand Mütsch @n1try 14:29
Yep and user registration logic would probably be handy as well. I get your concerns regarding the free enterprise solution problem
Michael Mayer @lastzero 14:30
I'm all for making progress and adding cool features, especially sharing will be very important when the foundation is implemented in good quality.
Ferdinand Mütsch @n1try 14:31
May I open GitHub feature tickets for multi-user support and shared albums?
Michael Mayer @lastzero 14:31
There should be tickets already
As mentioned, just adding multiple logins is easy but if you don't do it right it can easily end up being a performance and security nightmare
The database should be able to hold the index in memory which is tricky with many users and much more photos, especially when you start to use sharding. This is not done in one or two days like the login itself.
Ferdinand Mütsch @n1try 14:37
I agree...
Michael Mayer @lastzero 14:39
So for a family with not as many photos and no security concerns, it can be done later after thoughtfully thinking about the tradeoffs and implications. This needs to be documented very well too with big warning signs.
However, it would be better for performance to simply run multiple instances and use P2P sharing for albums.
For this, we might provide a central identity service with unique user name.
maybe ActivityPub support is better than multi-user.
@renothing ActivityPub support looks like a great feature for a later release 👍
Anyone experience with https://github.com/pixelfed/pixelfed?
I agree just being able to provide multiple login accounts (with the same roles etc) is already a good step forward.
Any news on this? 🙂
i'd like to one day see something like google photos where you can link an account with user/pass to view only selected albums they are assigned to
Working on link sharing next, except you don't create a new account every time you share. You can set a password and expiry date though.
is that a per photo things??
i like to add photos to an album and that album just gets bigger and bigger for the grand parents to view photos that get added to it.. just a nice simple "old person" proof way of letting them view all photos in the album
We start with albums, but technically you can share everything incl albums, labels, photos and files.
Cloud services such as nextcloud have already solved this problem. On the server the files are all owned by the cloud server and it decides who can view and edit the files.
You can already upload to and sync with Nextcloud, however image quality will not be the same and users won't see album title, description and other metadata.
Right, sorry, I wasn't implying you could use nextcloud to solve this problem, I was trying to imply we could use nextcloud solution as a template for solving this problem.
What does "unfounded" in this issue mean? Can one donate some amount of money specifically to move that feature forward? I would certainly pay for (a subset of) that feature to appear in the open source version.
See https://docs.photoprism.org/funding/
Yes, you can sponsor this and other issues. Ideally via GitHub Sponsors.
Hi @lastzero,
Do you have more information how it works? The doc is not clear on the priority of issues/improvement.
I mean, the is a goal/deadline (like Wikipédia by example/roadmap to achieve a specific issue? (only for information)
See public roadmap. It's not possible to give you a binding deadline like in a commercial software project unless you agree to cover our full expenses.
One thing I wonder about is how this would work with regards to the file structure on disk. E.g. is there only a single "originals" directory or one per user? If two users import the same photo do we store duplicate copies?
I think I'd lean towards a single deduplicated directory, but I'm not sure I've thought through all the various use cases.
@benmccann I think we should go for one originals folder. You are right we need to think through many use cases.
I guess in cases where two originals folders are needed one can run two instances and send files from one to another via webdav.
We'll add settings to limit users to sub directories, depending on the use case.
An import directory per user could make sense - then you'd have a way to know which user imported a photo
When implementing this, please support authenticated user headers, so people can use third party authenticating proxies like OAuth2-Proxy :-)
I'd love to be able to give people read only accounts of their own ...
Per user per dir might be better, just like DSM moments. It would be easy to import photo to photoprism user by user from other system.
This is now the only road blocker for me to migrate from google photo and moments to photoprism.
It would be great to have 'Group' spaces too - i.e. our community group has a photoprism instance, all photos in that space are shared with all users in the group.
It would be great to have 'Group' spaces too - i.e. our community group has a photoprism instance, all photos in that space are shared with all users in the group.
This goes into the direction as it's been implemented with the new Synology Photos Solution coming next release (DSM 7.0). I already using the Beta Version and very satisfied they merged there old Photostation and Moments Apps into one new app called Photos. There I have a personal photos space (images stored in my personal user space) and there is a public spcae where I can put images all users should have access to. Also I can create albums and share them with different users, which might go into the direction of grouping. Maybe it makes sense to have a look at the ideas of Synology Photo to reuse some of their concepts (if applicable).
Regarding the concerns about the complexity to introduce a user management system, I'd recommend to not start from scratch. One way would be to make use of solutions like casbin for ACL, RBAC and/or ABAC based policies. The project has first-class support for REST APIs and is used in many other large projects.
When it comes to the layout of the files on disk, I would not recommend to reflect the data to the representation of the application. It works fine for the initial indexing and import of new data, but storing files per user/group will add way more complexity and the chance for duplicated data.
The application should map data internally to users/groups while the actual storage path of a file is irrelevant and only required to serve the resource for API endpoints.
@svengreb are you sure, that casbin would be the way to go in context of access mangement for the files?
It sound great for common roles like admin, member, etc (roles that are able to see specific components / reach specific API Endpoints).
For the files it would be much easier and probably faster to create a mapping table for users who have access to which image (performance would increase in a document based db).
e.x.
Table Users
| ID | Username | ... |
|---|---|---|
| 1 | Bob | ... |
| 2 | Alice | ... |
Table Media
| ID | Hash | ... |
|---|---|---|
| 1 | 7degh6... | ... |
| 2 | h9jzwd... | ... |
| 3 | z4fsjpc... | ... |
Mapping Table
| ID_USER | ID_MEDIA |
|---|---|
| 1 | 2 |
| 1 | 3 |
| 2 | 1 |
| 2 | 2 |
| 2 | 3 |
If i request /media/7degh6... , the query would look like this:
SELECT * FROM MEDIA WHERE ID IN (SELECT ID_MEDIA FROM Mapping_Table WHERE ID_USER == current-user-from-session)Finally, Alice would be able to see the image while Bob receives an 403 Forbidden
For a more futureproof approach, one could use a ID_USERGROUP Map instead of ID_USER in case that some images should be shared with a specific group (e.x. the family). If one wants to share the image with a single person, there must be created an internal group that constists of the two parties.
EDIT
To keep the current system with the Backup files, one coul additionally store the members / groups in the yml file per Media (that could be imported after a db reset) like in a document based db.
I'd also like to fund this as this is the main point that still blocks me from using this as a drop in replacement for Google Photos.
I'd also like to fund this as this is the main point that still blocks me from using this as a drop in replacement for Google Photos.
Same for me!
Curious about this, as it is basically the thing currently delaying me in trying to deploy photoprism: does the plan here include having a tool to merge databases from multiple photoprism instances? In other words, can I currently deploy multiple photoprism instances, one per user, and then when this feature (and esp. shared albums) will land, expect to be able to merge all the databases to make sharing possible later on?
Also, as I see talk of a single deduplicated photo directory. Has the use case “each user has an associated nextcloud user with their own photos directory that is set as the photoprism directory” been taken into consideration, to avoid duplicating all the photos with one in nextcloud and one in photoprism? (though I guess for “group albums” that are rw by multiple people, it would make sense to have a separate photoprism folder as no single user should probably be responsible for the life of the file)
Merging databases would be more like a second or third step as this can be super complex, depending on your requirements. Seems best to keep separate databases / indexes for users who shouldn't see each others content in any way.
⚠️ IssueHunt is abandoned.
If you are putting money into it, you are losing it. Nobody will be able to receive that money as IssueHunt is not responding to withdrawal requests.
Just a heads up. It's best to just forget about it.
That'd be sad. Where do you have this information from?
People on spectrum, other users, and myself have not heard from them in over a year. They've walked away with the money, it seems. I'm writing Github about it now.
We received money once, but that was some time last year...
Has there been any progress on this feature ? Its really the only thing thats holding me back from using this otherwise great product. I think this is a essential feature.
@moximoti is working on it. Sadly, funding was holding us back in the past - and now it looks like IssueHunt is abandoned, so we might never get that money either.
I'm curious to hear if any of the people that require multi-user or multi-private features for their use-case have used a different privately hosted photo app in the interim. I'm looking for something - perhaps inferior - that can be privately used with mixed sets of users for a temporary project.
Ideally it works on folders so that it can be used in tandem with PhotoPrism, or as a temporary replacement
Yes, I currently use piwigo. It’s nice but doesn’t have object detection. I can’t use photoprism without multi user support. So I’ll stick to piwigo till it comes out at least.
The new Synology Photos is working well for me in lieu of Photoprism having this feature (but it means you need to buy a Synology NAS which is expensive). J
…
On 19 Jul 2021, at 08:33, gt2416 @.***> wrote: Yes, I currently use piwigo. It’s nice but doesn’t have object detection. I can’t use photoprism without multi user support. So I’ll stick to piwigo till it comes out at least. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
I use it currently but compared to photoprism, the UI is not good...
@danbenha has funded $50.00 to this issue.
* Submit pull request via [IssueHunt](https://issuehunt.io/repos/119160553/issues/98) to receive this reward. * Want to contribute? Chip in to this issue via [IssueHunt](https://issuehunt.io/repos/119160553/issues/98). * Checkout the [IssueHunt Issue Explorer](https://issuehunt.io/issues) to see more funded issues. * Need help from developers? [Add your repository](https://issuehunt.io/r/new) on IssueHunt to raise funds.
Ooops, should have read the whole discussion... Trying to cancel this, since the transaction is fresh 😅
Would love to push this issue specifically, instead of "just" funding the entire project via Github Sponsors. Maybe in the meantime until an alternative is found, could the number of Github Sponsors that back specific issues be counted?
We count the number of sponsors internally, and also maintain a public roadmap with upcoming features sorted by priority. As written above, @moximoti started working on this issue. It's important to properly implement security sensitive features like this, so development takes a significant amount of time that is well invested.
Keep in mind: Only getting paid for new features may quickly lead to bad software quality as existing functionality and infrastructure won't be maintained anymore.
We've implemented more features and improvements in the past months than most teams get done in a year, see release notes. That's why we sometimes need a break like everyone else, especially when it's 40°C in our office.
We count the number of sponsors internally, and also maintain a public roadmap with upcoming features sorted by priority. As written above, @moximoti started working on this issue. It's important to properly implement security sensitive features like this, so development takes a significant amount of time that is well invested.
Keep in mind: Only getting paid for new features may quickly lead to bad software quality as existing functionality and infrastructure won't be maintained anymore.
We've implemented more features and improvements in the past months than most teams get done in a year, see release notes. That's why we sometimes need a break like everyone else, especially when it's 40°C in our office.
That's good to know. Your point about software quality is well taken. I'm happy to start supporting the project via GH Sponsors (just need to make sure that this issuehunt thing is getting cancelled).
Nevertheless, this is literally the only feature that's holding me back from using PhotoPrism, so I wanted to give it a little push (recently trying to get my SO to upload vacation pictures to a shared folder on my Nextcloud was not very smooth in comparison to Google Photos 😅).
Wishing you a nice break, if you are having one, or an AC/fan if currently in your office 😄.
(Feel free to mark off-topic. This message doesn't add value to the discussion.)
Keep in mind: Only getting paid for new features may quickly lead to bad software quality
Yes, this is a common problem, not new. I'm surprised that IssueHunt/BountySource type solutions don't offer core maintenance fee options.
Ideally, the project owner can set a percentage - e.g. 30% of bounty payouts - that goes to the core team for maintenance of the general project. This way app maintenance is funded by people that rely on the app so much that they are willing to pay for features.
30% seems reasonable. That's what Apple asks for mere app store hosting, and they don't even maintain code to those apps. IssueHunt already takes a whopping 17%. BountySource takes 10%. Core dev team should get at least double of what the bounty payment provider gets imo.
Potentially relevant for recent funders via Issuehunt:
I filed a complaint about the credit card transaction with my bank, explaining the intended use and the abandoned state of Issuehunt. Also wrote an email to Issuehunt but, as expected, didn't receive a reply. Got a full refund from my bank (don't know if they somehow cancelled it or if this is an act of goodwill). I'm happy that I can now give this money to the project's team via Github Sponsors 😃
So, if your credit card was charged recently, this might be worth a try.
⚠️ IssueHunt is abandoned.If you are putting money into it, you are losing it. Nobody will be able to receive that money as IssueHunt is not responding to withdrawal requests.
Just a heads up. It's best to just forget about it.
Should people be cancelling their payments via issuehunt then and switching to, e.g. github sponsors?
@ark- we did not try to withdraw money from them recently (as our funded tasks are still in progress). I have found no official statement about it being abandoned. But some people seem to have problems getting their money.
Anyway we prefer Github Sponsors or Patreon.
So if you can get a refund from them we are happy to welcome you on Github Sponsors or Patreon :)
Very excited about this feature (hopefully i can convince my wife to use photoprism instead of google photos). Any update on the timeline for this getting into preview?
Hi @janstadt, it's already possible to create additional users via cli in the preview. However, there is no UI and no permission management yet. We're going to work on that after external authentication via OpenID Connect is implemented, which I'm currently working on. There's no exact time schedule, but we hope we'll be able to provide a basic implementation soon.
Can you tell us the commands? Will it be persisted when running in a docker container?
Just use photoprism users --help to find out about the subcommands.
E.g. to add a new user, you can just type photoprism users add. The cli will then prompt for your infos. To use this command without prompt, just pass username, email, password via flags as indicated in the subcommand's help page (photoprism users add --help)
Note, that the users subcommands are not final yet and syntax/behavior may still be changed in future iterations.
@AquaWolf yes, the users will be persisted In the database.
Hi @janstadt, it's already possible to create additional users via cli in the preview. However, there is no UI and no permission management yet. We're going to work on that after external authentication via OpenID Connect is implemented, which I'm currently working on. There's no exact time schedule, but we hope we'll be able to provide a basic implementation soon.
Awesome! Thanks will test it out.
Has the users subcommand changed? I'm running version 210523-b1856b9d-Linux-x86_64 in docker and I get No help topic for 'users' when I run photoprism users add in the container.
Has the users subcommand changed? I'm running version
210523-b1856b9d-Linux-x86_64in docker and I getNo help topic for 'users'when I runphotoprism users addin the container.
You'll need to pull the latest preview version i believe. Looks like youre running something from May.
@janstadt That's exactly the problem. That didn't even cross my mind given that I just pulled the container this morning. Changed to the preview docker tag and it works just fine. Thank you!
Is there a way to limit a specific users permissions for viewing specific originals yet? I've been able to successfully create an additional user but im curious if there is a way to allow them to only be able to access specific folders.
Thanks for pointing that out. I had just gotten to that comment. Lots of action on this issue! Pumped for this feature.
@moximoti Where are the docs on how to get the preview working?
We'll add docs to our User Guide once development is done. Multi user support is not officially released yet. The CLI commands included in our latest release should work though to create and delete (additional) admin users.
I am asking how to set up the preview environment so I can test too and use it.
I can run the preview version behind Basic access authentication. Then security-wise it should not be an issue.
You just need to change the Docker tag from latest to preview, or do you mean develop?
Preview and latest are the same right now as we have just released.
Thank you for this product, and this feature!
Am I correct in deducing so far that the multi-user functionality so far only allows a second "admin" user to be created, and therefor this user will have full access to all files uploaded as well as server settings? I know this is WIP, and it is really great, just want to make sure what I have tested so far does indeed align with what is being developed, and that I am not missing something.
This comment may help:
@Jc2k Thank you. I have indeed managed to create a second user via the CLI. So my findings are indeed aligned with what is currently being developed. Thank you again!
Thinking about multiuser in case of duplicated photo will be deduplicated and referencend only once?
Right, deduplication needs special attention. We think about separate databases in this case. You see why it takes so long! 😂
Also waiting for multiuser future :) ,will be great for famaly use...
Using Photoprism Docker in unraid (Linux x64)
So can we use mariadb for changing some users info after adding users ,for now, befor this future added or better to wait fo version with multiusers ?
Yes, this feature is still under construction so for your needs it's probably best to wait. I think this comment is still an accurate reflection of the current state of play:
And here points out that the feature is not released yet:
Multi-user is a hard thing to do well and can massively slow down database queries if implemented in a rushed way. So the team is rightly taking the time to do it right.
Hey! Do you all have a timeline on this project?
You mean a deadline?
@lastzero yes, deadline would be the appropriate comment. Very excited about the feature. Been checking it for months.
We have a zero bug policy and do our best to help users when they need support or have other questions, like right now.
This comes at a price, as we can't give exact deadlines for new features. Also, multi-user is really an epic. Some of it has already been built (run "photorism users help" in a terminal), some of it may be merged into develop this month, and there will be a lot of related features, like sharing, coming sometime next year.
Having said that, funding really has the highest impact. So users can do their part and become a sponsor to get their favorite features as soon as possible.
As you can see in our Release Notes and on the public Roadmap, we've decided not to release additional multi-user features before Christmas:
- This is partly because unexpected security vulnerabilities in Go and Log4j surfaced this month and we have a zero bug policy.
- In addition to providing support and fixing bugs discovered in the stable release, multi-user support is currently a top priority.
- Features are not released until we deem them safe and bug free. This is in the best interest of all users, part of our culture, and can't be debated.
- Users can do their part and become a sponsor to get their favorite features as soon as possible. At least until the funding goal is reached, please do not ask for deadlines.
Please don't add funds to IssueHunt anymore! 🎁
While we like IssueHunt and are grateful for the donations we've received so far, it hasn't proven to be a sustainable funding option for us as we spend much of our time maintaining existing features and providing support.
If we don't have enough resources to provide support and bugfixes, we can't start working on new features.
Yeah I know but I had $80 more dollars laying around there and as I will not get it out of issue hunt to put it in sponsoring I thought I may just add it to this feature in the hope of a wonder that issue hunt will pay out on this one.
Just a question: would it be possible, or, has anyone tried (if it's possbile) to run a asecondary instance or container for PhotoPrism as a readonly instance ? So running full version where i can manage uploads, tag people and update things, and another instance using the same cache and database in a readonly-mode that i can publish for my family members without them being able to screw things up .... Thats not true Multi-user but might be a good workarround in the mean time ...
Just a question: would it be possible, or, has anyone tried (if it's possbile) to run a asecondary instance or container for PhotoPrism as a readonly instance ?
Tried that by accident: It won't start and log that the storage directory is not writable.
Enabling read-only mode disables all features that require write permission to the originals folder, in particular import, upload, and delete. Editing of albums or other metadata stored in the database won't be disabled. The storage folder must be writable in any case. You're welcome to share related ideas and howtos in GitHub Discussions 🗯
Our team will continue to work on multi-user features shortly and release them once they are stable and tested:1
- We received a lot of support requests and other questions over the holidays and in the last few days. More than our team can handle.
- As a result, our priority was to expand the Troubleshooting Guide and divide it into subsections to make it easier for users to find common issues and fix them on their own. Many other parts of our docs were improved as well, for example Connecting via WebDAV.
- We felt that this made more sense than adding more and more features as quickly as possible.
Footnotes
-
Users can do their part and become a sponsor to get their favorite features as soon as possible ↩
Please don't add funds to IssueHunt anymore! 🎁
While we like IssueHunt and are grateful for the donations we've received so far, it hasn't proven to be a sustainable funding option for us as we spend much of our time maintaining existing features and providing support.
If we don't have enough resources to provide support and bugfixes, we can't start working on new features.
Can't wait for this, I'll start using Photoprism immediately.
I'm also VERY much looking forward to this. I'll be watching for the soonest I can try it. Thank you for all you've built here. I'm very pleased with how it's all coming along.
Keep up the GREAT work!
This would be amazing. I am counting the days until this happens!
Hey @brenty411 (and others)! Please don't add +1 comments, as they don't contribute anything to the discussion and just generate more email for the maintainers (and those who are subscribed to this issue) to go through. Instead, you can support issues by using GitHub's reactions feature (smiley icon at the top-right of each comment).
a good first step would be to allow the creation of a read-only user.
@hawkdavis This is the first step and already work in progress.
Just a question: would it be possible, or, has anyone tried (if it's possbile) to run a asecondary instance or container for PhotoPrism as a readonly instance ? So running full version where i can manage uploads, tag people and update things, and another instance using the same cache and database in a readonly-mode that i can publish for my family members without them being able to screw things up .... Thats not true Multi-user but might be a good workarround in the mean time ...
For me running multiple instances is a solid workaround. Make sure to use a different port for the new instance. Example from docker-compose.yml - using 2343 instead of default 2342
photoprism:
ports:
- "2343:2343" # HTTP port (host:container)
environment:
PHOTOPRISM_ADMIN_PASSWORD: "insecure" # !!! PLEASE CHANGE YOUR INITIAL "admin" PASSWORD !!!
PHOTOPRISM_SITE_URL: "http://localhost:2343/" # public server URL incl http:// or https:// and /path, :port is optional
PHOTOPRISM_HTTP_PORT: "2343"
Also make sure you are referencing different folders for your volume mounts
any progress so far?
any progress so far?
You see the progress in the commits that link to this issue and you will see that it's done when this issue is closed. Asking for progress doesn't speed up the development and can be annoying to the devs and anyone subscribed to this issue. What DOES help, and has been mentioned several times now, is funding the project via one of the many options available.
any progress so far?
This is the new login screen that was released last week. What do you think of it? Is this going in the right direction?
Check the commit logs and release notes for more changes and improvements:
You see the progress in the commits that link to this issue and you will see that it's done when this issue is closed. Asking for progress doesn't speed up the development and can be annoying to the devs and anyone subscribed to this issue. What DOES help, and has been mentioned several times now, is funding the project via one of the many options available.
A comment like this doesn't help. It comes across as snooty and rude. The fact that the "issue" has been open for over three years now with very little updates from the developers makes the question 100% legitimate.
I have no doubt the developers are doing their best, but considering it is one of, if not the, highest funded feature request, it would be nice with an update and some kind of estimated time when the feature might be available.
So you don't want documentation, support, bugfixes, and any of the other improvements we provide on a regular basis? 🤔
I do! In fact i've just increased my support level because theres nothing I hate more than entitlement in open source projects. It can be quite toxic, and when it is its disgusting. Let's hoping it doesn't turn toxic here everyone.
Thank you for valuing a stable code base and support!
So you don't want documentation, support, bugfixes, and any of the other improvements we provide on a regular basis? thinking
That's not what I said, and twisting my argument like that is, frankly, unfair.
Just like I said in my previous post, the mulitple user feature is the most requested and funded feature, treating people asking about it like like they are an annoyance and talking down to them is not, at least in my opinion, a good way to build a community.
If a lot of people constantly are asking about the same thing, don't you think that somewhere information is missing?
I have no problem with you completely axing the feature, or postponing it until 2025, that's fine, but please tell me if you are.
I have invested a lot of time into Photoprism. A lot of that is because over 9 months ago I was told "Actually working on this right now. Also building up a team to make progress faster. Give us a few weeks."
The multiple user feature is something I really need, and back then I thought it was just fine to live without it for a little while until it was polished and released is just fine. But after that I've heard nothing....
This is what we have in store right now. Looking at our feature list, that's a lot and mostly free. There's no reason to be disappointed and act like we've failed.
On the other hand, we have not reached our minimum funding goal even after years (!). Under these (repeatedly communicated) conditions, it is not helpful to ask for a deadline. Answering these questions over and over again - as we are doing now - wastes scarce resources that we could use for development.
As you can see in our commits and roadmap, we have not postponed this feature to 2025. However we have other tasks to take care of as well, and our team is too small.
I'm not sure I completely understand your post.
Is it this feature that is "in store"? If so, frankly, it has been for 3+ years...
As for funding, that is really unfortunate. I have tried most of all the other self-hosted applications out there and so far, Photoprism is really close to the top.
I can only speak for myself, but when I tested out Photoprism myself, the "multiple user" feature was kind of a must-have, and when I saw that the feature was on the todo-list I was encouraged. Less so when I saw it had been there for years...
So are other feature requests waiting for years. If you need this for your business, the solution is simple: Help us build a larger team!