I finally updated to Omeka S 3.1, but I am encountering a rather significant issue. All new items are now assigned by default to all available sites.
To clarify, as far as I understand there are two locations where this setting can be changed:
at the site level, by enabling the “assign new items by default” option (in my case, only one site has this enabled)
at the user level, by listing which should be the default values for a given user.
Both settings seem to be disregarded: whenever I create a new item, this is assigned by default to all sites. The assignment can be removed manually, but this implies more than a dozen clicks for each new items… tedious and error-prone.
Further things I tried, to no avail:
enabling and disabling the relevant option at the site/user level
trying with different users (admin/editor)
Somewhat puzzingly, when I create a new item with an editor that doesn’t have access to all sites, Omeka kind of seems to want to assign those as wells, leaving blank lines in the list:
The item is then not actually added to those sites, only to the ones the user has access to.
Even if I create a new site after upgrade, then all new items are assigned to that as well, no matter the site settings.
As things stand, I will probably revert to the previous version, unless you have good suggestions for further troubleshooting/fixing this. Perhaps I am just missing something obvious. Thanks a lot!
Together with the update to 3.1, I also upgraded to php8, but the issue emerges even keeping php 7.4.
Quick update to add that all seems fine looking at the logs, and having the site in “development” mode does not show any error. Adding a default site at the user level pre-update does also not change anything.
The only somewhat related issue I remember is this one: Regression in Omeka S 3.x: " All item sets have been added."
Unlike in that case, the selector here works nicely, but also in this case it shows the text: “All sites have been added.” in English, no matter the locale. I’m mentioning this only because it’s related to a selector and to a fix only recently introduced in the codebase, but it may well be completely unrelated.
Any suggestion for further troubleshooting is welcome.
Thanks a lot for looking into this and the quick response, it’s sincerely appreciated.
If I understand this correctly, this means there’s nothing “broken” in the database during the update process, is that correct?
If so, and we can expect that the undesired behaviour of the selector will then be fixed with some future update, we can probably continue using 3.1 paying extra-caution to the site tab.
