This can be due to
 - very slow server
 - too many allocated projects (I saw instances where each user was allocated to 2000 projects, this in nonsense)
 - admin connecting with the check version enabled but server cannot access the internet (waits for timeout of connection)

Thanks for the answer, but why have many projects slow the login system?

Because rights are defined at project level.
So calculation of rights is done at login, taking into accout : all available screen, default profile of user, profile of user on each project, inheritance of project profile on sub-project (recursively).
So the more project, and the more allocations, the more complex the calculation is...

Okay thanks. And is there any way to improve this? Or the only way to do it is to delete affectations?

Hi Babynus,

May you advise whether closed, cancelled and deleted project's related data e.g. task, allocation will be calculated as well at login? If calculated, I think that could be a potential further reduction of login time to exclude the closed, cancelled and delted project's related data at login.

Thanks,
Rainbow

May you advise whether closed, cancelled and deleted

This is already optimized

Hi Babynus,

This subject on performance in relation to allocation management is interesting.

You indicate:

- too many allocated projects (I saw instances where each user was allocated to 2000 projects, this in nonsense)

Imagine the case where we actually have 2000 projects, all under the same main project, and the users of a team must have access to all of these projects (simple assumption).

To allocate these users, 2 possibilities:
1) Allocate these users on the main project only (the simplest and most consistent)
2) Allocate these users to each of the 2000 sub-projects

Will configuration # 1 be significantly more powerful / faster for users ?

Or is it the same for the system because it has to go through all the projects (or if the effective rights are precomputed) ?

Do you think setup # 1 is similarly nonsense because users should never have access to 2000 active projects ?

Thanks   

I think both will have same performance, possibly case 1) a bit faster (but no very)

Case 1) in nonsense as there is no reason to allow everyone on 2000 projects. Only some supervisors may need to view all these projects.
Case 2) is even worse, as allocating on all 2000 projects will be very long and ugly to manage

Possibly best solution is a case 3) to give to everyone a right that give access to all projects.
Maybe this may be significantly quicker than cases 1) and 2)

Thank you for these answers.

Possibly best solution is a case 3) to give to everyone a right that give access to all projects.
Maybe this may be significantly quicker than cases 1) and 2)

For this case 3, are you thinking of a right managed according to profiles and access modes (existing functionality) or a new functionality ?

In the example I imagined, users should not have access to all projects. They should only have access to all subprojects of the main project mentioned, but other main projects would be accessible to other users only.
Is an optimization adapted to such a case possible ?

Case 1) in nonsense as there is no reason to allow everyone on 2000 projects. Only some supervisors may need to view all these projects.

However, there may be reasons, in my opinion, for all the resources of a team to have access to all the projects processed by that team (although 2000 projects is probably overkill).
Here are the reasons I'm thinking of :
[list=A]

The same goes for all the projects of this team.​​​​​​​

The same goes for all the projects of this team.

The same goes for all the projects of this team.

For each of these cases, it is not manageable to allocate only the necessary resources / users to each (sub) project. Above all, the result would be that of case 2 mentioned in my previous post.

Isn't my way of looking at things the right way ?
How do you think these needs should be managed ?

Thanks

Hi,

I allow myself to come back to this subject concerning my previous post.
Could you please have some answers and advice for me ?

Thanks

For this case 3, are you thinking of a right managed according to profiles and access modes (existing functionality) or a new functionality ?

Play with existing access rights management.

In the example I imagined, users should not have access to all projects. They should only have access to all subprojects of the main project mentioned, but other main projects would be accessible to other users only.
Is an optimization adapted to such a case possible ?

Then allocation to parent project with adapted profile should work.

Isn't my way of looking at things the right way ?

The way you look a t things in, in general, the way that best fits your need.

How do you think these needs should be managed ?

This seem too complexe to explain each case here.
But I think that playing with acces rights will give an answer.
For instance, you can try new planning modes with "is responsible for" so that you give visibility / write access just set responsibility to the item.

Thanks for these tips.
I will study these suggestions