-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2.1.9 upgrade, Projects module shows the number of projects in filter tabs, but "No projects available" to view #56
Comments
There were some performance enhancements in task lists, although I think that was post 2.1.9, but that is about the only thing I can think of that may have touched on that area. Let me dig a little.
|
This is using the docker container config I talked to you about earlier, and pulls the master branch as is - none of the performance enhancements we worked on were included. |
Hi Adam, |
So there was an export and import that caused this? It sounds very much like the permissions cache hasn't come across cleanly. In the change from 2.1.3 to 2.1.4 there was a change to speed up permissions handling by creating a permissions cache table and populating it from the phpgacl tables. If you look at db/upgrade_213_to_214.sql you'll see how it was doing that. It may be you need to run a similar query to re-populate the cache. |
I just did a mysqldump of our live database (our standard backup procedure) and brought that dump into the new db instance - the dump is completely generic, all tables, no trickery. I grabbed the sql query you mentioned, replaced the %dbprefix% vars appropriately and ran it against my db. I had to re-login, but the issue is still there |
Hi Adam, I've also tried using the official MySQL docker images - 8.0 and 5.7 had compatibility issues, but 5.5 connected, but still exhibited the same issue - |
Possible fix for #56 - needs testing
@cleary take a look at this change - it works on my system with your data, my only concern is that it may introduce other subtle permissions bugs, but I believe the ordering should now be valid - if not I suspect we may need to review the permissions cache and how it is being used, and perhaps look for a better way of caching the GACL lookups. |
I think there are some unacceptable side-effects of this latest change, I'm going to revert it - just noticed that admin can't see companies, for instance. |
Seems it was an unrelated issue with companies drop down.
And I've just reinstated it as the companies issue was nothing to do with permissions - a further fix will follow. From looking at this it does seem to resolve most of the permissions issues. Please give it a try and see how you go. |
Hi Adam, |
I think just look at those things that are related to the permissions you have set up, so for instance try viewing contacts, companies, departments, tasks and see that they align. I suspect that in the long run we may want to look at a better caching mechanism, as that does have a lot of overhead - every time you update any permission it completely rebuilds the permissions cache, and I don't think that will scale. |
That isn't great. Back to the drawing board then. |
@cleary I've just reviewed both the original code, the code on your installation, and the changes I made and realised that the changes on your installation actually make sense, while the original code could never work. I've committed that change so it should now be the same as your running install. |
Thanks Adam, gave it a test and it's working now |
Hi Adam,
I'm testing the upgrade to v2.1.9 - for all our non-admin users, they are no longer able to get a listing of projects in the Projects module:
The filter tabs indicate correctly how many should be visible.
The permissions/roles haven't changed since our 2.1.8 deployment, and look like this (for this particular example):
The Project Worker role looks like:
Is there something I'm missing that's changed in the role?
The text was updated successfully, but these errors were encountered: