Make tone options configurable

Created on 25 March 2023, over 1 year ago
Updated 3 November 2023, 8 months ago

Problem/Motivation

The tone options are currently hardcoded:

'#options' => [
            'friendly' => t('Friendly'),
            'professional' => t('Professional'),
            'helpful' => t('Helpful'),
            'easier for a high school educated reader' => t('High school level reader'),
            'easier for a college educated reader' => t('College level reader'),
            'explained to a five year old' => t('Explain like I\'m 5'),
],

it would be better to allow site admins to define their own list, both the label (right) and the value (left).

Steps to reproduce

Proposed resolution

Allow site admins to define their own list, both the label (right) and the value (left). This could either be taxonomy or a config entity list.

Remaining tasks

User interface changes

API changes

Data model changes

πŸ“Œ Task
Status

Active

Version

1.0

Component

User interface

Created by

πŸ‡ΊπŸ‡ΈUnited States kevinquillen

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @kevinquillen
  • First commit to issue fork.
  • πŸ‡ΊπŸ‡ΈUnited States mitchel432

    Sorry to take this from you @kevinquillen, I had just built a similar feature so this was easy for me to do again. Here is what I added

    • Entity Config for Tones
    • Fields prompt, temperature, and weight
    • Adjusted .module to now use Tones

    I went with config entity to allow for more fields. I thought the ability to adjust the temperature for each prompt was a nice to have.

    This is just a start, as I didn't write any tests. Let me know what you think and if there should be any changes.

  • @mitchel432 opened merge request.
  • πŸ‡ΊπŸ‡ΈUnited States kevinquillen

    Nice work. Does this mean that if I create 100 tones, does it export 100 yamls?

  • πŸ‡ΊπŸ‡ΈUnited States kevinquillen

    I think a simpler solution would be configuration that lets users select Vocabulary taxonomy that is relevant here, then the only configuration exported is for the new vocabulary definition. The extra fields could still live in the form (not on the term) and or as global config.

Production build 0.69.0 2024