Users problem

RichardB

We have a very large collection of photos which, to convert to zenphoto, I have divided into several sections.

We have been creating special Users which use only one section of a first level folder as its allocated 'Managed Album'; - eg. in this collection,
https://graves.eggsa.org/northwest/
a 'user' who is limited to the folder 'North West, BRITS, Urban area' as its 'Managed Albums'.

This makes working much quicker than logging in to the whole site to edit in just one area.

When I refer to a 'user' I am referring to the user as created under the Users tab.

We now find a strange problem - after some time (variable - hours, days) the 'user' in question loses its 'Managed Albums'. Suddenly the person logged in as that user is no longer able to edit - when one goes back to the User's tab the managed album or albums are no longer registered there.

We have been unable to see any rhyme or reason to this.

Over to you!

Hope you can help,
Richard

acrylian

First time we hear about that issue. That would mean the database is updated as those settings are stored there.

Please check your logs. And perhaps also look at the administrators table in the db. We had users with database issues causing duplicated entries.

Although those were options and such if I remember correctly. Those were not our issue but somehow the tables were not correctly setup with unique columns.

RichardB

This always happens after a database update.

There is nothing to be seen in the debug log.

In the administrators database table, can I presume that the managed album or albums is stored in the code of field 'rights' ?

So, if the access to the managed album is lost at some update, then it is the 'rights' coding that is altered?

Thank you,
Richard

acrylian

No, "rights" stores the rights level of the user. You cannot directly see the manage albums as they are connected via the "admin_to_object" table. Exception is the prime album if you have enabled that which has is id stored in the column of the same name.

RichardB

OK, thank you - I see that.

So judging from another of these incidents this morning, and looking at the database tables, that means that it is the admin_to_object entry that has been lost or removed when updating the database.

I have asked the people involved to see if they can spot whether it is an update of images or of albums (or both) that is triggering this.

We have not used 'prime' albums. I will check your tutorials to gen up on them.

Thank you,
Richard

RichardB

Had a look - no, we don't use 'Primary' albums. We have many top level albums and need to switch from one to another as needed.

We have been using the 'managed' albums to speed up using the backend and as we usually work only on one or sometimes two albums (when moving images or albums) this is very convenient for us and it has certainly speeded things up.

Richard

RichardB

This is still happening pretty frequently and is a nuisance.

Presumably for the Administrator to lose its connection to the object_to_admin entry, the Administrator must be being saved as well as the album or image that has been edited?

I wonder why that would be?

If the user is not being saved again, how can the managed album be dropped from his admin_to_object table?

I would very much like to get this sorted out.

Thank you for your help so far.

Richard

acrylian

It does not reset itself unless you are saving an admin or change rights. There is also the "prime album" that is created on user creation e.g. by the register_user plugin if enabled. That is not set via admin_to_object but within the adminstrators tables.

But bottomline I have no idea why that would be happending if you don't have any actual error messages…

What PHP version are you using, which of the two database handlers and what database?

Also check the tables and look if the admin_to_object values match. It connects the id of the admin with the id and type of the object. Sadly you have to manually look up with the other tables if those match.

acrylian

One thing although it makes no real sense if it works and then changes: Do you use the user_groups plugin? Make sure you have them assigned to a group that matches. For example the default group viewers has no management rights. Also there is a mistake - we never realized until now - that you can assign a user to more than one group which results in unclear rights.

RichardB

Thank you - you asked:

What PHP version are you using, which of the two database handlers and what database?

PHP version: 8.2.27

Database: MySQL 8.0.40
Database handler: mysqli
Database client: mysqlnd 8.2.27

and the database tables are of type innoDB

the admin_to_object appear to match with the administrator table and the users in the Users tab.

this is an actual report (as an explanation - having converted from Menalto Gallery 2 we have many images that need rotating);::

[Working on one album among those in my Managed Album] I rotated photos and had already done 5 pages (20 images each) in an album with 194 images . Going to the 6th page, I was reverted to this page [this was the Upload tab of the Admin section, with message: there are no albums to which you can upload] and I am no longer able to do any editing.

I am still logged in, but have no editing rights. You'll see when you go to my username [the folder I was working on] is no longer ticked in the Managed Albums drop down list.

acrylian

Okay, we haven't done real testing with MySQL 8 yet as our local server tool had some upgrade problems: Our server uses MariaDB with a matching version though MariaDB and MySQL now start to divide since the last upgrade but we haven't noticed anything wrong yet. We had fixed one MySQL 8 issue that was reported a while back but we cannot exclude that there is more…

Thanks for a guide to possible reproduce this. Mysterious that you would get redirected to the upload tab when you are only rotating…

RichardB

So will you continue to develop this software for MYSQL ?
Our users are still encountering this problem frequently.
Thank you,
Richard

acrylian

We don't develop specifially for MySQL or MariaDB and currently don't use specific code for each, except in one place because of MySQL 8. If we really need to use code specific for them we will use internal switches like that as well.

We still don't have yet access to MySQL 8 yet as the newer version of your local setup tool is currently still not properly. Once it does - which it did at least for 10+ years - we will check it.

But I doubt that the issue you encounter has directly to do with MySQL 8 directly.

• Check via phpmyadmin or else if the tables are setup correctly and have the intended unique columns indices set. Post the data of the tables here.
• Post the exact rights these users have enabled please.

RichardB

I am not sure which tables you are referring to, or how to know which should have indices but here are those for 3 tables:

administrators
in table structure 3 keys
id
user
valid
indexes: Primary (id)
valid and user

albums
in table structure 2 keys: id and folder

indexes Primary (id)
         folder

images
in table structure 3 keys: id, alubmid, filename

indexes Primary (id)
             filename
             albumid 

None of the other tables have indexes.

--

You asked: Post the exact rights these users have enabled please.

Albums: View fullimage, View unpublished, Upload
Gallery: View gallery, view search
General none
Managed albums - usually one
but could be two if the user has to move albums

--

users are mainly adding titles to already uploaded images,
but some may also be revolving images (having converted from Menalto Gallery 2 many images are sideways on)
and some may be moving albums or images.

---

There are no errors to be found in the debug log referring to these occasions when the user loses the right to the managed album. This always seems to happen at the point of saving.
I have not examined the php error logs as these are more difficult to access but I can do so if necessary.

---

Thank you,
Richard

acrylian

Tables actually look good. Please take also a look at the admin_to_object table.

Sorry if I asked before:

• Do you use user groups actually or do you set
• This is version 1.6.5 I assume

RichardB

Sorry - missed that one
admin_to_object has one Primary index on id, of type BTREE

Yes version 1.6.5
This is a large collection and consists of 11 installations of Zenphoto, all 1.6.5 and the user problem shows up in at least 5 of them (not all of them are currently being edited).

https://graves.eggsa.org/

We don't use groups. We have just one main administrator who uploads photos, but a number of editors who caption the uploaded photos, or do other maintenance work.

We found that trying to work with full admin access to all folders is simply too slow so we have users who have access either just to one top level folder and its underlings if they are editing, or to two top level folders if they are moving items.

Thank you,
Richard

acrylian

We tested around but sadly we cannot reproduce your issue with the loosing rights. We used this rights setup and two assinged albums: https://www.zenphoto.org/test/userrights.jpg.html

We rotated and moved images between those two albums and never lost our access.

The only thing I currently could think of is filesystem permission issues so Zenphoto somehow considers the albums as "new". The internal assignment is stored via the ID so any "new" album would get a new ID and the rights assignment would get lost.

We tested with 1.6.6a locally.