Yes, security has been reinforced.
If profile has no access to a given screen, he cannot acces items of this Class.

We just found (this morning) that this may have unexpected behavior in some cases, as some configurations may use this security leak.
if UserX has default profile P1 and is allocated to project Y with profile P2.
Profile P1 can see screen of object O (defined in habilitation) and P2 cannot see it, but with acces to data, P1 can see "items of his projects" and P2 also.
Before the fix, UserX could access to Objects of class O on project Y, depite the fact that profile P2 has not access to Screen of objects O.
So this is due to misconfiguration of access rights on the allocation profile.

We are working on workaround to loosen constraints but keep security enforced.
So if default profile of user X gives him access to screen of Object O, we won't systematically block access to data of projects where user has profile with no access to the screen.
It is the access to data that will tell if user can see item or not.

The resource experiencing this problem has the same default profile and the same profile across all projects. It can no longer assign itself to an activity or even a meeting; the "+" icon no longer appears in the assignment area.

It is an issue dur to security straightening.
Since this update, user cannot upsate assignments if they don't have access to assignment screen.

This issue has been fixed and fix is available through subscription.