Cloudlog 2.0 - Multi-Client, Multi-Logbook, Moving to Database Settings taking things forward

[dg9vh]

Problem
I am often asked about the client capability of cloudlog. Actual developments are in the direction to have one log that could be filled by different users in the system and/or one user with different station-profiles that is a perfect solution for multiop-Stations like clubstations where one callsign is operated by different users for example.

What users also asked is to have one instance of installation for different users with their own log.

Solution
We could create a new field in the logging-table called "client" or similar that refers to one dedicated client instance. So we can manage all log-entries as usual in one logging-table but could filter in general on that client id.

The client-id should be maintained within an own table like station_profile only by administrators. We should also consider about a relation-table client_user that would map a user to one or more clients and vice versa (n:m-relation).

The log-view so should present only those logentries that matches the client-ids that the user is mapped to (but also those QSOs of other users mapped to this client-id).

[dm-o]

Yes - would be a very nice feature for our DARC chapter to give every member a personal logbook as a free service.

[magicbug]

While I totally get people to want to start offering Cloudlog as a SaaS to others, it wasn't really its fundamental plan at the early stage and to get it to that stage you'd need to consider the following

• Implement a logbook table which assigns to station profiles, logbook being whats assigned to a user.
• Logbook ID in the QSO table
• Table to link Users to Logbooks
• Table to Link Users from their Logbooks to Station Profiles
• eQSL/Clublog/LOTW settings all need split off and stored differently to support "club members" callsigns.
• QRZ/HamQTH logins need to be shifted to the database (This needs done anyway) but encrypted along with the other logbook services.
• Any config item in config/cloudlog.php needs moved to the database and collected on login.

For good database design, it requires a bit more than just a column in the log ID, it will be something that I start looking into, but functions will require a bit more than you imagine.

[dg9vh]

Hi Peter,
you are right - my idea was very incomplete and only a first shoot within 5 minutes when typing the issue :-)

I think this is more than a point of coding, more than a strategical decision, what way cloudlog should go.

This decision is not done by my person, I only could give some impulses from feedback from our users out there.

So if we decide to go the way to make cloudlog completely usable for different client situations, we are good positioned, if we first go to have a concept to do this before coding into the blue.

As you mentioned, this would be a lot of work but it could also be a big effort for the users.

On the other hand I have no count how many percent of the logs would profit on this... So we just go and think about the pro's and con's and then take a decision on this.

Kim

[magicbug]

Yeah, my comment was "not going to happen" more there's far more involved.

My personal long term plan is users will be able to create logbooks, station profiles of their own and use them.

It might be easier to split it into parts, so switching configs to the database, make active station profile not a global but on the user account.

[dg9vh]

So there is a 1:n-relation between users and logs? means: one user can have several logs but a log only can be filled by one user?

If so, this would be a step back from where we are now... actually cloudlog could perfectly be used in a multi-user-environment where we have n users on the system logging to one log. I think, this feature should stay in future also to make cloudlog interresting for clubstations logging contact for example for special-event-stations on different locations/times and so on. This is a use-case I personally see more often than the wish to provide a central-logging-server for all club-members and their individual logs - but this wish also exists :-)

So as you said: there would be much work in making a good concept to solve this use-cases. Taking all the configuration-parts into the database would also be better than having it locally on files.

Cloudlog could provide some central information tables like dxcc and so (this would be same for each user within the instance) and otherwise several tables that are client capable.

We should invest some time into thinking about a solution :-)

[magicbug]

Those might be aware theres a PR #383 now thats been submitted, I think its now time to actually consider how multi-client might actually work in Cloudlog as ultimately this is a breaking change for most.

I'm going to just dump my lunchtime thoughts here as bullets so hopefully aren't terrible.

• Cloudlog is clearly based around one user having many logbooks (station profiles) with the master user holding the keys to most of the functions like LOTW, Clublog logins etc.
• Sub users are really just for logging QSOs but not much else.

What would need to happen

• Redefine how user accounts work, a user would need to be able to create their own station profiles, or be assigned to one that exists on another account.
• eQSL, Clublog, QRZ, LOTW settings would all need to be handled I'd guess on a per-user level.
• The current display for dashboard/logbooks/search when your not logged in would be a reasonably failed concept once a "user could create their own"
• APIs would need to be stored against a user_id

Thoughts, opinions, I'm cautious on implementation as this will ultimately break some parts of Cloudlog for old installs

Pete, 2M0SQL

[magicbug]

Okay, spent some time this evening and started building out a specification, its a Word document I know that doesn't suit everyone, its worth noting that this should be classed as a breaking change so not something to take lightly.

I start to look at considering what needs to happen and table changes.

Cloudlog 2.0 - Multi-Client Implimentation.pdf Rev 0.1

[dh9dat]

Hi Pete,
thanks for the document, my first thoughts after reading it (only commenting some of the points since I haven't examined all of the code, especially not the API system etc. but only the logbook and some other parts I needed to deal with in my PR in thread #383):

• Requiring login, isn't this already controlled by config['auth_mode']? Meaning, if this is set to a value greater than 0, a login is required to see anything, or am I wrong? (Can't really test it ATM since my installation is a bit different because of the changes I've made)
• Who should be able to create new logins? Self-registration would be nice, but I think this would at least require some kind of anti-spam mechanism (for example Recaptcha or similar), and perhaps some more advanced techniques against misuse
• Perhaps we should implement a lost password function, for example sending a one-time password by mail
• Search: Just an idea, what do you think about a drop-down box allowing to narrow down the search (entire database, your station profiles, only active profiles)?
• How can we safely store the personal data which should be encrypted, to ensure no-one can decrypt it (except of brute-force attacks, of course)?

Harald, DH9DAT

[ofadam]

What's the difference between "cloudlog-v2" and "multilogbook" branches?

[vielmetti]

I'm wondering about the name for this, and the one that comes to mind is "Clublog". Good luck with the system design, and when it comes time to test anything, I'm happy to give feedback and reports.

[magicbug]

Cloudlog name is already established so bit confused by the suggestion to change.. work on V2 continues although running in random with master makes it a slow process.