Skip to content
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

Closed
wants to merge 27 commits into from
Closed

fix(metadata): Disable updates to metadata #3376

wants to merge 27 commits into from

Conversation

joshmarnold
Copy link
Contributor

@joshmarnold joshmarnold commented Jul 25, 2023

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.

Scenario Can View Metadata on a folder Can apply a Metadata template to a folder* Can edit/delete Metadata on a folder* Can enable/disable Cascade Metadata Can see if folder* Metadata is being cascaded
Allowed user - No Metadata on folder YES YES YES n/a n/a
Allowed user - Metadata on folder (no cascade) YES YES YES YES YES
Allowed user - Metadata on folder with cascade YES YES YES YES YES
Disallowed user - No Metadata on folder YES YES YES n/a n/a
Disallowed user - Metadata on folder (no cascade) YES YES YES NO YES
Disallowed user - Metadata on folder with cascade YES YES NO NO YES

@joshmarnold joshmarnold requested a review from a team as a code owner July 25, 2023 14:42
@@ -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"
Copy link
Contributor

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?

Copy link
Contributor Author

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

@joshmarnold joshmarnold requested a review from a team as a code owner July 26, 2023 14:32
src/features/metadata-instance-editor/Instance.js Outdated Show resolved Hide resolved
src/features/metadata-instance-editor/Instance.js Outdated Show resolved Hide resolved
src/features/metadata-instance-editor/Instance.js Outdated Show resolved Hide resolved
src/features/metadata-instance-editor/Instance.js Outdated Show resolved Hide resolved
src/features/metadata-instance-editor/Instance.js Outdated Show resolved Hide resolved
src/features/metadata-instance-editor/Instance.js Outdated Show resolved Hide resolved
Copy link
Contributor

@tjuanitas tjuanitas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

src/features/metadata-instance-editor/Instance.js Outdated Show resolved Hide resolved
src/features/metadata-instance-editor/Instance.js Outdated Show resolved Hide resolved
@joshmarnold
Copy link
Contributor Author

joshmarnold commented Jul 28, 2023

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 MetadataSidebar and I haven't had the opportunity to look into it. I don't see its use in EUA to try to test it out. As of now, I can only report that the tests are passing, which is good. It seems similar to MetadataInstanceEditor in that they both render the Instances component. However, there is a difference, MetadataSidebar is not utilizing the isCascadingPolicyApplicable property, which would have rendered it incompatible with cascading policies. Due to my lack of knowledge about the intended purpose of the MetadataSidebar, I cannot definitively state what the expected behavior should be or whether any updates are necessary.

Copy link
Contributor

@tjuanitas tjuanitas left a 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

src/features/metadata-instance-editor/Instance.js Outdated Show resolved Hide resolved
src/features/metadata-instance-editor/Instance.js Outdated Show resolved Hide resolved
src/features/metadata-instance-editor/Instance.js Outdated Show resolved Hide resolved
@@ -52,8 +52,9 @@ type Props = {
hasError: boolean,
id: string,
intl: Object,
isCascadingPolicyApplicable?: boolean,
isCascadingPolicyApplicable: boolean,
Copy link
Contributor

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();
Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Contributor

@tjuanitas tjuanitas left a 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/Instance.js Outdated Show resolved Hide resolved
src/features/metadata-instance-editor/Instance.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();
Copy link
Contributor

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

Comment on lines 218 to 227

const cascadePolicyData = {
...cascadePolicy,
isEnabled: isFolderInstance ? isCascadingEnabled : false,
overwrite: isCascadingOverwritten,
};

const clonedCurrentData = cloneDeep(currentData);
const JSONPatch = this.createJSONPatch(clonedCurrentData, originalData);
onSave(id, JSONPatch, cascadePolicyData, clonedCurrentData);
Copy link
Contributor

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?

Copy link
Contributor Author

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

Comment on lines +290 to +293
cascadePolicy={{
id: 'hello',
}}
isCascadingPolicyApplicable
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@tjuanitas
Copy link
Contributor

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

@joshmarnold
Copy link
Contributor Author

Found a way to do this without changes to BUIE.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants