[#53704] Visible=false project attribute values are deleted when a non-admins edit the attributes #15296
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dombesz
force-pushed
the
bug/53704-visible=false-project-attribute-values-are-deleted-when-a-non-admin-user-edits-the-attributes
branch
2 times, most recently
from
cbd02e5 to
69012c5
Compare
dombesz
force-pushed
the
bug/53704-visible=false-project-attribute-values-are-deleted-when-a-non-admin-user-edits-the-attributes
branch
from
69012c5 to
de85bc6
Compare
…n-admin user edits the attributes https://community.openproject.org/work_packages/53704
…ok and also disable non available custom fields. We have a few callbacks that interfered with the disable_custom_fields_with_empty_values being on the after_create callback. For example the CustomValue model also has an after_create callback activate_custom_field_in_customized_project which overwrites the changes we do in the disable_custom_fields_with_empty_values. This makes all the custom fields with a custom value to be activated, regardless of the changes we do in the disable_custom_fields_with_empty_values. Since we want the disable_custom_fields_with_empty_values to have the final word, it is moved into a before_commit hook, which will be executed after the activate_custom_field_in_customized_project.
…ommit hook and also disable non available custom fields." This reverts commit de85bc6.
This is a compromise solution to avoid further patching the acts as customizable plugin, because it will be removed anyway. This behaviour does not manifest on the UI, so it does not present a real problem.
dombesz
force-pushed
the
bug/53704-visible=false-project-attribute-values-are-deleted-when-a-non-admin-user-edits-the-attributes
branch
from
499a0ff to
db7942c
Compare
dombesz
deleted the
bug/53704-visible=false-project-attribute-values-are-deleted-when-a-non-admin-user-edits-the-attributes
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://community.openproject.org/work_packages/53704
The problem
When a custom field is hidden (
visible=false) for non-admins (usually for project admins), it is cleared out while the project custom fields are updated from the sidebar. This happens because the hidden field is not submitted with the form, and theacts_as_customizableplugin will clear all the fields that are not submitted.The solution
In order to fix the issue, we should also include the hidden fields in the backend when assigning the updated custom fields. To make this happen, we have to return the hidden fields too from the
available_custom_fieldsmethod, when the_query_available_custom_fields_on_global_levelis set to true. This flag signals to the plugin, that we want to request the available_custom_fields globally as opposed to requesting the project enabled custom fields.Due to the complexity of the acts_as_customizable plugin and the plugin patch, the fix causes 1 test to fail. The test ensures, we do not activate hidden fields when they are being submitted by non-admin users. This contradicts the bug we are fixing here, because we have to assign the hidden field on the backend in order to not lose its value and its activated state.
This is not a critical issue, because it does not manifest on the frontend, and it will not allow setting any value for the hidden field either. I will provide a fix for the failing testcase in the next minor release.