[digiKam-users] Multi-user digiKam setup?

[Gilles Caulier]

Hi,

The multi users setup require severals works in digiKam database interface.

Outside the fact that you need to use a remote Mysql Database, this needs a
lock mechanism to prevent concurrents access to the contents. Of course
this want mean a to share the same database contents (collection) between
users.

A first approach is to work like shared document between Words we users can
change contents. A lock mechanism is done to open document in RW for the
first people, and in Read only for all others. This less powerful but this
simplify the workflow to manage. A versionning system is also required in
this configuration.

They are some files already open in bugzilla about this topic. We will need
to found a new student to work on this project next summer.

Best

Gilles Caulier

Le ven. 30 nov. 2018 à 09:30, Stefan Müller <stefan.mueller.83 at gmail.com> a
écrit :

> Good morning Leo,
>
> I'm gonna face the same problem, so I mentioned in [digiKam-users] Use
> digiKam with a NAS and MariaDB
> <http://digikam.1695700.n4.nabble.com/digiKam-users-Use-digiKam-with-a-NAS-and-MariaDB-tp4707031p4707346.html>,
> where it is a bit off-topic.
>
> I haven't got the chance yet to pursue that topic. That could be just the
> right place.
>
> I'm wondering if the new plug-in model would allow to
>
>    - intervene SQL queries to an NAS based database
>    - do authentication against e.g. an LDAP server
>
> stefan
> Am 30.11.2018 um 02:02 schrieb Leo Gaspard:
>
> Hello world!
>
> I have tried IRC to bother the fewest possible people, but it looks like
> #digikam at irc.freenode.net is dead, so let's try here. Sorry for the
> noise! (Note: I am not subscribed to the list, can you please keep me in
> the Cc: list?)
>
> I am considering using digiKam, but as my use case is kind of peculiar,
> I thought I would first ask whether you think I have chances of
> succeeding at what I'm trying to do.
>
> Context: I'm trying to setup a shared photo database with my family for
> all our photographs. Photos will be shared over NextCloud, and hopefully
> digiKam would be used to both tag them and synchronize the tags. Now,
> the photo database is kind of huge, and not all computers are able to
> download it in full. In addition, not everyone has the same taste for
> photos, so I think it'd be better if everyone only had write access to
> their own directory, and read access to others'.
>
> My currently imagined solution:
>  * Each user puts their pictures in their write-for-them read-for-all
>    folder in Nextcloud
>  * Everyone runs a digiKam instances. Tags are synchronized either
>    through MySQL or by just adding the SQLite database to the Nextcloud
>  * digiKam is setup to directly fetch the photos from WebDAV from the
>    Nextcloud instance
>
> So my questions are:
>  1. Do you have advice on whether to pick MySQL or synchronize the
>     SQLite database over Nextcloud? (I will have linux, windows and mac
>     clients)
>  2. Does digiKam handle well-enough collections on read-only folders?
>  3. What do you think about the overall idea?
>  4. Bonus question: Ideally users could also have their own private
>     databases that are not shared. Does digiKam handles properly
>     switching between two databases, ideally  with one that includes the
>     other?
>  5. Trick question: If an answer is no, is there any project other than
>     digiKam that could handle these requirements and that you would know
>     about?
>
> I've searched a bit the manual and didn't find much about these
> questions, and I must say I'd rather request an opinion from someone
> knowledgeable before starting the setup, that will likely be kind of
> long and complex, especially if done with MySQL. Sorry if the questions
> are already answered someplace I didn't find!
>
> Cheers, and thank you for digiKam that looks like some nice piece of
> software!
>   Leo
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20181130/3c288907/attachment.html>