Login very slow

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   

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 :

1. A (sub) project is really processed by only one or two resources, but it concerns a product which, in the future, will be the subject of frequent new projects. The resources that will address these future projects can be any member of the team. To carry out these future projects, they will need to access the old projects of the product in order to know its detailed history.
   The same goes for all the projects of this team.​​​​​​​
2. The main activities of a (sub) project are really processed by one or two resources only, but some very short tasks (tickets) can be handled by any member of the team, depending on availability at a time T, therefore not defined in advance.
   The same goes for all the projects of this team.
3. A (sub) project on which almost all the resources of a team will intervene, each for an activity of its own (activity A => resource 1, activity B => resource 2, activity C => resource 3, etc. ).
   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