[Remove Vuetify from Studio] Send e-mail dialog #5487

Prashant-thakur77 · 2025-10-21T06:13:46Z

Summary

This PR completes the removal of Vuetify from the Send Email dialog as part of the larger Vuetify migration effort (#5060). The dialog now uses Kolibri Design System components exclusively while maintaining all existing functionality.

Changes Made:

✅ Replaced VDialog and ConfirmationDialog with KModal

✅ Replaced VFlex and VLayout with custom CSS flex styles

✅ Replaced VForm with native form element

✅ Replaced VTextField and VTextarea with KTextbox

✅ Replaced VTooltip with KTooltip

✅ Implemented form validation using generateFormMixin

✅ Created new StudioChip component to replace VChip

References

Sub-issue of #5060.

Reviewer guidance

Login as [email protected] with password a
Go to Administration > Users
Select few users in the table
Click Email

Visual Changes:

Minor styling differences due to KDS vs Vuetify
Consistent with Kolibri Design System patterns
Maintains all existing functionality

…lose function

LianaHarris360

Thanks so much for updating the EmailUsersDialog component. This is a good start so far. There’s still a couple of Vuetify components that can be removed. The VBtn and VCardText can be replaced with KButton and a div. There’s also a few user-facing strings that still need to be translated. The KModal title, the From and To labels within the form, “Subject line”, “Email body”, and the phrase “Add placeholder to message”, and all of the placeholder labels.

LianaHarris360 · 2025-10-24T18:07:06Z

contentcuration/contentcuration/frontend/administration/pages/Users/EmailUsersDialog.vue

+        </div>
+        <div class="email-textarea">
+          <KTextbox
+            ref="message"


Now that this "message" ref references KTextbox, on line 261, we need to update it to include $el to avoid this error in the console:
"TypeError: Cannot read properties of null (reading 'focus')"

LianaHarris360 · 2025-10-24T18:45:42Z

contentcuration/contentcuration/frontend/administration/pages/Users/EmailUsersDialog.vue

+          <KTextbox
+            ref="message"
+            v-model="message"
+            :label="'Email body'"


The text for this label should be a translated string $tr

LianaHarris360 · 2025-10-24T18:51:30Z

contentcuration/contentcuration/frontend/administration/pages/Users/EmailUsersDialog.vue

+    :submitText="$tr('sendButton')"
+    :cancelText="$tr('cancelButton')"
+    data-test="email-dialog"
+    @submit="submit"


The method to send the email is named onSubmit , it should be updated here and on line 15 in the <form> as well.

LianaHarris360 · 2025-10-24T18:57:10Z

contentcuration/contentcuration/frontend/administration/pages/Users/EmailUsersDialog.vue

+  <KModal
+    v-if="show"
+    :size="600"
+    :title="'Send Email'"


This KModal title should be a translated string

Administration plugin is an exception. Since it's used internally, we don't translate strings. A general rule of thumb is to preserve the original approach: If there is a translated string - use it, if there is an untranslated string - use it :)

LianaHarris360 · 2025-10-24T18:58:04Z

contentcuration/contentcuration/frontend/administration/pages/Users/EmailUsersDialog.vue

+          :showLabel="true"
+          :appearanceOverrides="getAppearanceOverrides(errors.subject)"
+        />
+        <div class="caption grey--text">Add placeholder to message</div>


This phrase should be a translated string

LianaHarris360 · 2025-10-24T19:07:54Z

...ation/contentcuration/frontend/administration/pages/Users/__tests__/emailUsersDialog.spec.js

      expect(wrapper.vm.showWarning).toBe(true);
    });

+    it('should not show warning when canceling with no draft content', async () => {


This a great addition to test for, thanks for including this!

LianaHarris360 · 2025-10-24T19:13:35Z

contentcuration/contentcuration/frontend/shared/views/StudioChip.vue

+      },
+      handleClose() {
+        this.$emit('close');
+        this.$emit('input');


We shouldn't need to emit both close and input. I think in this case, only emitting close is more clear.

LianaHarris360 · 2025-10-24T19:24:52Z

contentcuration/contentcuration/frontend/shared/views/StudioChip.vue

+      'studio-chip--active': isActive,
+    }"
+    :style="chipStyles"
+    @click="handleClick"


This div should be converted into a real button if it is meant to be interactive and clickable.

thanks for the review @LianaHarris360 .I would like a suggestion on what to do here i think we can complelely get rid of the clickable feature . what are your thoughts on it .we will keep the kicon button clickable and the rest will be same?

and if we want to make it interactive can u tell me how to apply hover and clickable effects to kbutton.This would be helpful in this and here

The VBtn and VCardText can be replaced with KButton and a div

I’ve replaced the VBtn and VCardText components with KButton and a div. However, I’m facing a bit of confusion while trying to apply the hover and clickable effects similar to those in VBtn. Could you please guide me through how to implement these interactions correctly or share a reference example where this has been done? It would be really helpful.

I will add a bit more nuance:

(1) Whole-area-clickable chips

These need to be <button> s. To ensure proper a11y-related behaviors.

KButton is not suitable for this purpose. It's quite a different component compared to a chip-like-button. You can use native <button>.

(2) Chips with clear X button

I think that these would be best <div>s with the inner clear <button>.

Here KIconButton for X could be good, but if there are any specific challenges, raise them here please and we can decide if there's something we need to update in KDS, or if the native <button> would be more suitable.

LianaHarris360 · 2025-10-24T19:27:19Z

contentcuration/contentcuration/frontend/shared/views/StudioChip.vue

+        </slot>
+      </div>
+
+      <KIconButton


This icon button needs an accessible name attached to it, like ariaLabel ="Remove {username}", using the KIconButton ariaLabel prop.

Prashant-thakur77 · 2025-10-25T06:50:36Z

@LianaHarris360

There’s also a few user-facing strings that still need to be translated. The KModal title, the From and To labels within the form, “Subject line”, “Email body”, and the phrase “Add placeholder to message”, and all of the placeholder labels.

I have a doubt related #5426 (comment) this.Here i was told that wrapped strings are not to be used in administraion.So please do tell what i need to do here in this context

MisRob

Chiming in with some additional notes.

Overall congratulations on your first more complex issue. Overall nice work. All main features seem to be preserved Thanks for examining the current experience carefully.

MisRob · 2025-10-28T11:10:05Z

contentcuration/contentcuration/frontend/administration/pages/Users/EmailUsersDialog.vue

+  <KModal
+    v-if="show"
+    :size="600"
+    :title="'Send Email'"


Administration plugin is an exception. Since it's used internally, we don't translate strings. A general rule of thumb is to preserve the original approach: If there is a translated string - use it, if there is an untranslated string - use it :)

MisRob · 2025-10-28T11:20:30Z

...ation/contentcuration/frontend/administration/pages/Users/__tests__/emailUsersDialog.spec.js

For this file, I would recommend to take the same approach that I suggested in your other PR. For the same reasons.

MisRob · 2025-10-28T11:23:24Z

contentcuration/contentcuration/frontend/shared/views/__tests__/StudioChip.spec.js

+  });
+};
+
+// Configure Testing Library to use data-test attributes


I appreciate that you were attentive to the current naming. This would better be done on the global configuration level though. And since we don't really yet have a pattern for VTL, you can remove it and use the default attribute. If I recall that's what most other VTL test suites use.

MisRob · 2025-10-28T11:25:07Z

contentcuration/contentcuration/frontend/shared/views/__tests__/StudioChip.spec.js

+    expect(screen.queryByTestId('remove-chip')).not.toBeInTheDocument();
+  });
+
+  test('applies small class when small prop is true', () => {


There is no need to test for the presence of a class. It won't say that much about the resulting experience. Typically we just test markup, content, and logic.

Same applies to other similar tests in this file.

MisRob · 2025-10-28T11:34:25Z

contentcuration/contentcuration/frontend/shared/views/StudioChip.vue

+      'studio-chip--active': isActive,
+    }"
+    :style="chipStyles"
+    @click="handleClick"


I will add a bit more nuance:

(1) Whole-area-clickable chips

These need to be <button> s. To ensure proper a11y-related behaviors.

KButton is not suitable for this purpose. It's quite a different component compared to a chip-like-button. You can use native <button>.

(2) Chips with clear X button

I think that these would be best <div>s with the inner clear <button>.

Here KIconButton for X could be good, but if there are any specific challenges, raise them here please and we can decide if there's something we need to update in KDS, or if the native <button> would be more suitable.

MisRob · 2025-10-28T11:40:58Z

contentcuration/contentcuration/frontend/shared/views/StudioChip.vue

+      },
+    },
+    mounted() {
+      document.addEventListener('click', this.handleClickOutside);


It is quite unusual to add event listener to style active/inactive state. What was the reason for doing it in this way? Have you tried to use common hover and focus styling approaches?

Thanks @MisRob — you’re right, typically hover/focus styling would handle active/inactive states more cleanly.

In this case, the event listener was added to detect clicks outside the component to toggle the isActive state off when the user clicks elsewhere on the page. This was mainly done to simulate a “chip selection”interaction where the chip remains active after being clicked, and only deactivates when the user clicks outside of it.

However, I agree that for purely visual feedback (like hover/focus), CSS pseudo-classes would be more appropriate. I can refactor it to use CSS states for hover/focus, and only keep the event listener if we still need outside-click detection for interaction purposes.

Thanks for explaining. @Prashant-thakur77. I think it'd be a bit more suitable to use state for what you're trying to achieve, but perhaps we don't even need it. For now let's just use CSS and remove the event listener completely. We will then preview and see.

contentcuration/contentcuration/frontend/administration/pages/Users/EmailUsersDialog.vue

MisRob · 2025-10-28T11:50:08Z

contentcuration/contentcuration/frontend/administration/pages/Users/EmailUsersDialog.vue

+    margin: 2px;
+  }
+
+  /* Custom layout styles to replace Vuetify flex system */


It wouldn't be meaningful to have a copy of Vuetify utilities in this specific file. They are used across the whole Studio, and at some point, we may actually remove them. Please delete these copies and just apply styles to containing elements without using the utilities, in a similar way you do above this section.

MisRob · 2025-10-28T11:59:01Z

contentcuration/contentcuration/frontend/administration/pages/Users/EmailUsersDialog.vue

+          :showLabel="true"
+          :appearanceOverrides="getAppearanceOverrides(errors.subject)"
+        />
+        <div class="caption grey--text">Add placeholder to message</div>


Would you remove all these Vuetify helpers classes?

Relatedly, for color-related ones, such as here grey--text, KDS theme tokens and palette approach needs to be used instead.

Please revisit the whole file.

MisRob · 2025-10-28T12:03:06Z

contentcuration/contentcuration/frontend/administration/pages/Users/EmailUsersDialog.vue

+          return {
+            ...baseStyles,
+            focusBorderColor: this.$themeTokens.error,
+            focusBoxShadow: `0 0 0 2px ${this.$themeTokens.error}33`,


Do these focus... take effect actually?

Also, I think it'd be fine, and even better for consistency, to just go with the default error state for KTextbox.

Perhaps you can upload a screenshot of what you're trying to achieve and explain why, and then we can decide.

I agree it makes sense to stay consistent with the default KTextbox error state and avoid introducing separate handling unless absolutely necessary.Will update it

Prashant-thakur77 added 21 commits October 13, 2025 20:57

Created for the ConfirmationDialog

ddfff2a

Maintained proper functionality of discard Draft button by updating c…

896eb95

…lose function

Made a base for studiochip

00d487f

added kbutton to cancel and send mail

b098e20

made some changes for ktextbox

d32cd39

correcting email body width

dba7779

added textarea to ktextbox

3636589

corrected textarea dimensions

9474f9b

Implemented Ktootip and remove Vflex

0fa6d56

added Generate form mixin Functionality

cae6965

Fixed minor Generate form mixin Functionality

d456c3f

Updated StudioChip component and replaced vchip fron emailusersDialog

11e05d9

Created testfil for StudioChip Component

3f2707d

Corrected color in StudioChips

53ca2a0

Updated Testfile for StudioChip Component

88779de

Updated Tests for emailusersdialog

1343180

removed hovering and added clicking functionality

62312a3

added corresponding tests for the functionality

98ed4a5

nowrap feature

93e88c0

removed etra styles

32a6fa8

removed comments

e1c72de

Prashant-thakur77 changed the title ~~Remove vuetify email dialog~~ [Remove Vuetify from Studio] Send e-mail dialog Oct 21, 2025

removed comments

d9bded2

rtibbles requested a review from LianaHarris360 October 21, 2025 15:47

rtibbles assigned LianaHarris360 Oct 21, 2025

Prashant-thakur77 added 2 commits October 23, 2025 00:27

Removed StudioBanner as no such requirement was mentioned

b2e8476

Removed StudioBannertests

f701169

LianaHarris360 requested changes Oct 24, 2025

View reviewed changes

MisRob requested changes Oct 28, 2025

View reviewed changes

MisRob added the hacktoberfest-accepted label Oct 28, 2025

[Remove Vuetify from Studio] Send e-mail dialog #5487

Are you sure you want to change the base?

[Remove Vuetify from Studio] Send e-mail dialog #5487

Uh oh!

Conversation

Prashant-thakur77 commented Oct 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes Made:

References

Reviewer guidance

Visual Changes:

Uh oh!

LianaHarris360 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Prashant-thakur77 Oct 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Prashant-thakur77 commented Oct 25, 2025

Uh oh!

MisRob left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Prashant-thakur77 commented Oct 21, 2025 •

edited

Loading

Prashant-thakur77 Oct 25, 2025 •

edited

Loading