Content
View differences
Updated by Markus Kahl over 5 years ago
### **Environment**:
Your OpenProject Version: 11.1.2
### **Steps to reproduce:**
1. Create a user custom field for projects
2. Create 1000 users and 10,000 projects
3. Assign a number of those users to each of the projects.
4. As an admin try to create a new project
### **Actual Behavior**
Accessing the new projects page (/projects/new) will timeout.
### **Expected Behavior**
Accessing thenew projects page should work like normal.
# Discussion
The issue occurs while trying to determine the allowed values for the user custom field when trying to create a new project.
When editing a project only users who are member in that project are possible values for the project's user custom field.
During creation, however, OpenProject allows [any and all users](https://github.com/opf/openproject/blob/dev/app/models/custom_field.rb#L278-L287) who are member in project visible to the current user. When this user is an administrator and there are a great many users and projects this will result in a very slow query. This causes the request to time out.
**Solution**
Now one solution would be to make that query faster.
However, it can be argued that it's not necessary to even list all users who a member in another project. Editing the custom field only allows actual project members of that particular project.
Hence we suggest that during project creation the user custom field should not be allowed to be set at all and have no possible values to begin with. The field should be disabled and a note/tooltip should say that it can only assume the value of project members, meaning it can be set as soon as one has added some.
This means in particular that [this branch](https://github.com/opf/openproject/blob/dev/app/models/custom_field.rb#L283-L284) should simply return an empty result set.
**Further implications**
The core issue lies with `Principal.in_visible_project_or_me` which is too expensive when there are many projects and users.
This means not only creating new projects is broken in such a scenario, but using the _principal filter_ too, as well as the _principal API_ endpoint.
Your OpenProject Version: 11.1.2
### **Steps to reproduce:**
1. Create a user custom field for projects
2. Create 1000 users and 10,000 projects
3. Assign a number of those users to each of the projects.
4. As an admin try to create a new project
### **Actual Behavior**
Accessing the new projects page (/projects/new) will timeout.
### **Expected Behavior**
Accessing thenew projects page should work like normal.
# Discussion
The issue occurs while trying to determine the allowed values for the user custom field when trying to create a new project.
When editing a project only users who are member in that project are possible values for the project's user custom field.
During creation, however, OpenProject allows [any and all users](https://github.com/opf/openproject/blob/dev/app/models/custom_field.rb#L278-L287) who are member in project visible to the current user. When this user is an administrator and there are a great many users and projects this will result in a very slow query. This causes the request to time out.
**Solution**
Now one solution would be to make that query faster.
However, it can be argued that it's not necessary to even list all users who a member in another project. Editing the custom field only allows actual project members of that particular project.
Hence we suggest that during project creation the user custom field should not be allowed to be set at all and have no possible values to begin with. The field should be disabled and a note/tooltip should say that it can only assume the value of project members, meaning it can be set as soon as one has added some.
This means in particular that [this branch](https://github.com/opf/openproject/blob/dev/app/models/custom_field.rb#L283-L284) should simply return an empty result set.
**Further implications**
The core issue lies with `Principal.in_visible_project_or_me` which is too expensive when there are many projects and users.
This means not only creating new projects is broken in such a scenario, but using the _principal filter_ too, as well as the _principal API_ endpoint.