-
Notifications
You must be signed in to change notification settings - Fork 305
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(metadata): Disable updates to metadata #3376
Conversation
@@ -569,6 +571,7 @@ class Instance extends React.PureComponent<Props, State> { | |||
data-resin-target="metadata-instanceedit" | |||
onClick={this.toggleIsEditing} | |||
type="button" | |||
data-testid="metadata-instance-edit-button" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RTL doesn't recommend using extra test attributes unless necessary, do we need to add a testid to this button? Are we able to find the IconEdit and click that instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now using the aria-label
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
have changes been tested with ContentSidebar?
https://github.com/box/box-ui-elements/blob/master/src/elements/content-sidebar/MetadataSidebar.js
@tjuanitas I was not aware of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you might be able to achieve the desired behavior in EUA using the editors
prop that's being passed into MetadataInstanceEditor
for example, if the instance in the map has template.templateKey === TEMPLATE_CUSTOM_PROPERTIES
, then you would omit the cascadePolicy
property since that's not applied for custom instances. similarly, you could set the canEdit
property based on isFolderMetadataCascadeEnabled
/ the split treatment.
this way when the values get to this Instance.js
component, the props more accurately represent the desired behavior. e.g. the canEdit
prop and the method this.canEdit
should for the most part return the same value
@@ -52,8 +52,9 @@ type Props = { | |||
hasError: boolean, | |||
id: string, | |||
intl: Object, | |||
isCascadingPolicyApplicable?: boolean, | |||
isCascadingPolicyApplicable: boolean, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I this intentional? metadata.js
is still using isCascadingPolicyApplicable?: boolean,
@@ -590,8 +581,7 @@ class Instance extends React.PureComponent<Props, State> { | |||
shouldShowCascadeOptions, | |||
isCascadingOverwritten, | |||
}: State = this.state; | |||
const isProperties = template.templateKey === TEMPLATE_CUSTOM_PROPERTIES; | |||
const isEditing = this.isEditing(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would imagine the performance impact is minor but consider that you are now calling isEditing()
n times instead of storing the result
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree, I think the original is cleaner too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
changes were confirmed to work with File
metadata in the sidebar right?
overall implementation makes sense but left minor comments
src/features/metadata-instance-editor/__tests__/Instance.test.js
Outdated
Show resolved
Hide resolved
src/features/metadata-instance-editor/__tests__/Instance.test.js
Outdated
Show resolved
Hide resolved
@@ -590,8 +581,7 @@ class Instance extends React.PureComponent<Props, State> { | |||
shouldShowCascadeOptions, | |||
isCascadingOverwritten, | |||
}: State = this.state; | |||
const isProperties = template.templateKey === TEMPLATE_CUSTOM_PROPERTIES; | |||
const isEditing = this.isEditing(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree, I think the original is cleaner too
|
||
const cascadePolicyData = { | ||
...cascadePolicy, | ||
isEnabled: isFolderInstance ? isCascadingEnabled : false, | ||
overwrite: isCascadingOverwritten, | ||
}; | ||
|
||
const clonedCurrentData = cloneDeep(currentData); | ||
const JSONPatch = this.createJSONPatch(clonedCurrentData, originalData); | ||
onSave(id, JSONPatch, cascadePolicyData, clonedCurrentData); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
little confused on why this change is needed. in the original implementation, it was only passing cascadePolicyData
when the policy was applicable. but now it's passing cascadePolicy
in all cases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Relevant EUW service: https://git.dev.box.net/AppServices/end-user-web/blob/25e47e8a54c6a19f666d15e3ddf3ac09c158807a/src/server/controllers/metadata/saveInstances.js
please reference this as I think it will help understand what's going on here
cascadePolicy={{ | ||
id: 'hello', | ||
}} | ||
isCascadingPolicyApplicable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i see isFolderInstance
is not added here, does the current implementation allow for the isCascadingPolicyApplicable
and isFolderInstance
props to work independently of each other? is that okay?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They're testing that the footer renders properly. Whether or not the footer renders doesn't depend on these variables.
I also want to make sure the cases here are considered in the testing: https://opensource.box.com/box-ui-elements/#/Features?id=metadatainstanceeditor i.e. showing the correct error states or messages |
Found a way to do this without changes to BUIE. |
Summary
There is an option in the Admin Console that allows an admin to restrict which users have the ability to create cascading metadata. At some point in the not-so-distant past (sometime in the last 6-12 months as of July 2023) the feature was broken. Users who previously did not have the ability to create cascading metadata could now do so.
Background/History
When folder level metadata was introduced, it seems like it was intended to be synonymous with cascading metadata. That is not the case today. It’s true that most folder level metadata is cascaded, but it’s not the only use case.
It also appears that with the way the feature was built, it not only restricted cascading metadata, but restricted ALL metadata adds/edits to folders. I believe this was a side effect of the previously mentioned belief that folder = cascade.
An important note to keep in mind with all of this is that the feature was built at the UI layer. Meaning, any user with edit capabilities, irrespective of the Admin Console option, could add/edit/delete folder level metadata or apply/remove cascading metadata via the API. In simpler terms, we put a roadblock in place, but this was NOT a security control.
The intent behind this feature is to allow web users to be editors of folders but not allow them to add cascading metadata to those folders.
Solution Requirements
There are 4 options an admin can select for this feature. Those are: “Enable for all managed users”, “Disable for all managed users”, “Enable for select users”, and “Enable for everyone except select users”. To make things simple, users in the following requirements will be denoted as “allowed users” or “disallowed users” regardless of how the status was obtained. We’ll also assume that all users have Editor permissions to the folder in question.