CCM-11966: Change button text and TemplateStatus on frontend #759
Conversation
… reflect new data if routing is enabled
… reflect new data if routing is enabled
utils/utils/src/enum.ts
Outdated
|
|
||
| const templateStatusToDisplayMappingsLetter = (status: TemplateStatus) => | ||
| statusToDisplayMappings[status]; | ||
| const isProofEmpty = ( |
There was a problem hiding this comment.
This returns true if template.files.proofs in non-empty, right?
Should this be called isProofAvailable instead?
utils/utils/src/enum.ts
Outdated
| ? templateStatusToDisplayMappingsLetter( | ||
| template.templateStatus, | ||
| isRoutingEnabled, | ||
| isProofEmpty(template) |
There was a problem hiding this comment.
Shift right option:
You could get rid of templateStatusToDisplayMappingsDigital and templateStatusToDisplayMappingsLetter, you could rework statusToDisplayMapping like this:
It'd mean that you don't need to introduce the TEMPLATE_PROOF_APPROVED status on the open api spec and into the type system.
export const statusToDisplayMapping = (
template: TemplateDto,
isRoutingEnabled: boolean = false
): string => {
const statusToDisplayMappings: Record<TemplateStatus, string> = {
NOT_YET_SUBMITTED:
template.templateType === 'LETTER' ? 'Not yet submitted' : 'Draft',
SUBMITTED:
template.templateType === 'LETTER' &&
isRoutingEnabled &&
isProofAvailable(template)
? 'Template proof approved'
: 'Submitted',
DELETED: '', // will not be shown in the UI
PENDING_PROOF_REQUEST: 'Files uploaded',
PENDING_UPLOAD: 'Checking files',
PENDING_VALIDATION: 'Checking files',
VALIDATION_FAILED: 'Checks failed',
VIRUS_SCAN_FAILED: 'Checks failed',
WAITING_FOR_PROOF: 'Waiting for proof',
PROOF_AVAILABLE: 'Proof available',
} as const;
return statusToDisplayMappings[template.templateStatus];
};
utils/utils/src/enum.ts
Outdated
| VIRUS_SCAN_FAILED: 'Checks failed', | ||
| WAITING_FOR_PROOF: 'Waiting for proof', | ||
| PROOF_AVAILABLE: 'Proof available', | ||
| TEMPLATE_PROOF_APPROVED: 'Template proof approved', |
There was a problem hiding this comment.
| TEMPLATE_PROOF_APPROVED: 'Template proof approved', | |
| PROOF_APPROVED: 'Template proof approved', |
more in line with the others, plus I feel like "template" is implied given its a TemplateStatus?
| user.clientId | ||
| ); | ||
|
|
||
| console.log('clientConfigurationResult', clientConfigurationResult); |
There was a problem hiding this comment.
just a comment to make sure these get taken out before merge
| .resolves({ Attributes: databaseTemplate }); | ||
|
|
||
| const response = await templateRepository.submit(id, user, 0); | ||
| const response = await templateRepository.submit(id, user, 0, false); |
There was a problem hiding this comment.
I think we should have another two tests in here now, instead of one - one from PROOF_AVAILABLE and one from PROOF_APPROVED?
| channelIdentifier: 'letter', | ||
| PageModel: TemplateMgmtSubmitLetterPage, | ||
| expectedHeading: "Approve and submit 'valid-letter-submit-template'", | ||
| expectedHeading: "Approve 'valid-letter-submit-template'", |
There was a problem hiding this comment.
think we should have additional tests in here for whether the flags are enabled/disabled, using the different users?
| expect(container.asFragment()).toMatchSnapshot(); | ||
| }); | ||
|
|
||
| it('should render with client proofing disabled', () => { |
There was a problem hiding this comment.
| it('should render with client proofing disabled', () => { | |
| it('should render with client proofing and routing disabled', () => { |
| ':expectedLetterStatus': 'PROOF_AVAILABLE' satisfies TemplateStatus, | ||
| ':expectedLetterStatus': isRoutingEnabled | ||
| ? ('PROOF_APPROVED' satisfies TemplateStatus) | ||
| : ('PROOF_AVAILABLE' satisfies TemplateStatus), |
There was a problem hiding this comment.
@m-salaudeen if routing is enabled, you should never get here, right? So the expected letter status should always be PROOF_AVAILABLE?
There was a problem hiding this comment.
Yes it shouldn't, but this check is only making sure the right status is there when changing to SUBMITTED.
…approve_and_submit_content_changes
…rove_and_submit_content_changes
5 participants
Description
Context
Type of changes
Checklist
Sensitive Information Declaration
To ensure the utmost confidentiality and protect your and others privacy, we kindly ask you to NOT including PII (Personal Identifiable Information) / PID (Personal Identifiable Data) or any other sensitive data in this PR (Pull Request) and the codebase changes. We will remove any PR that do contain any sensitive information. We really appreciate your cooperation in this matter.