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

PER-9935 Support V2 requests to /record/copy #151

Draft
wants to merge 2 commits into
base: PER-9255-clear-date-on-backend
Choose a base branch
from

Conversation

iulianvsp
Copy link
Contributor

No description provided.

Copy link
Member

@liam-lloyd liam-lloyd left a comment

Choose a reason for hiding this comment

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

In investigating the existing copy endpoint, I realized that while this is certainly a useful effort, it isn't actually pressing, the capability that I thought we needed a V2 version for actually exists already. So I think we should still do this, but you're welcome to prioritize other tickets over it.

const validation = Joi.object()
.keys({
...fieldsFromUserAuthentication,
RecordVO: {
Copy link
Member

Choose a reason for hiding this comment

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

The concept of a VO isn't used in stela

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, so we don't want to keep backwards compatibility then? I was trying to keep the request format the same.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, this does not need to be backwards compatible

Comment on lines +54 to +59
archiveNbr: Joi.string().optional().allow(null),
folder_linkId: Joi.number().integer().optional().allow(null),
parentFolder_linkId: Joi.number().integer().optional().allow(null),
parentFolderId: Joi.number().integer().optional().allow(null),
folderId: Joi.number().integer().optional().allow(null),
uploadFileName: Joi.string().optional().allow(null),
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we need any of these fields

@@ -64,3 +66,21 @@ recordController.patch(
}
}
);

recordController.post(
"/copy",
Copy link
Member

Choose a reason for hiding this comment

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

I think the path here should be "/{recordId}/copy"

.keys({
...fieldsFromUserAuthentication,
RecordVO: {
recordId: Joi.number().integer().required(),
Copy link
Member

Choose a reason for hiding this comment

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

recordId should probably be a URL parameter for this endpoint

folderId: Joi.number().integer().optional().allow(null),
uploadFileName: Joi.string().optional().allow(null),
},
FolderDestVO: { folder_linkId: Joi.number().integer().required() },
Copy link
Member

Choose a reason for hiding this comment

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

I'd use folderId rather than folder_linkId. Ideally callers of the API never need know what a folder_link is.

uploadFileName: Joi.string().optional().allow(null),
},
FolderDestVO: { folder_linkId: Joi.number().integer().required() },
archiveId: Joi.number().integer().optional().allow(null),
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we need this field?

Comment on lines +40 to +42
// Do we need need to check for read access?

// Do we need to check for create permission in target folder?
Copy link
Member

Choose a reason for hiding this comment

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

Yes. The relevant places to check are the account_archive entries binding the calling account to the archive(s) where the record and destination folder live, plus any access records associated with the record and/or folder

Copy link
Member

Choose a reason for hiding this comment

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

Also we should check for publish permissions on the record if it's being copied to a public folder

Copy link
Member

Choose a reason for hiding this comment

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

Also checking for write permissions on the destination should include the check that it's not a connector folder.

Comment on lines +52 to +62
RecordVO: {
recordId: Joi.number().integer().required(),
archiveNbr: Joi.string().optional().allow(null),
folder_linkId: Joi.number().integer().optional().allow(null),
parentFolder_linkId: Joi.number().integer().optional().allow(null),
parentFolderId: Joi.number().integer().optional().allow(null),
folderId: Joi.number().integer().optional().allow(null),
uploadFileName: Joi.string().optional().allow(null),
},
FolderDestVO: { folder_linkId: Joi.number().integer().required() },
archiveId: Joi.number().integer().optional().allow(null),
Copy link
Member

Choose a reason for hiding this comment

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

Also note that IDs are always strings in stela. Numeric types should only be used if we expect to do arithmetic or numeric comparison with a value

export const copyRecord = async (
recordData: CopyRecordRequest
): Promise<FolderRow> => {
// TODO check space over - How to check if there is enough space?
Copy link
Member

Choose a reason for hiding this comment

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

The account_space table keeps the running total of the space available to an account. The account to check is the calling account, unless the archive where the destination folder lives has payerAccountId set, in which case that's the account to check.

@iulianvsp iulianvsp force-pushed the PER-9255-clear-date-on-backend branch 2 times, most recently from e631148 to c827e36 Compare December 4, 2024 15:19
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.

2 participants