* fix: [MICROBA-1903] validate date time
Currently, we do not validate date and time to be a date on the future on the front end. We do handle this on the backend. This updates form validation to force the user to enter a data in the future.
* refactor: replaced Pending Tasks with alert and made general styling/accesibility updates
* addressed linter flags
* refactor: replaced Pending Tasks with alert and made general styling/accesibility updates
* fixed linting issues again
* refactor: replaced Pending Tasks with alert and made general styling/accesibility updates
* fixed checkbox responsiveness and darkened text under input
Co-authored-by: Maxwell Frank <mfrank@2u.com>
The various form states were getting mixed up during error handling,
which lead to some strange situations where the cancel button was
appearing when it shouldnt have been. This PR centralizes all of the
form state changes into a useEffect hook to handle any and all state
changes throughout the form. This approach not only centralizes the
fragmented code, but prevents the state mixups that were happening
previously.
It also has the added benefit if down the line more state changes need
to be added, the changes are all happening in one place.
* refactor: replaced Pending Tasks with alert and made general styling/accesibility updates
* addressed linter flags
* refactor: replaced Pending Tasks with alert and made general styling/accesibility updates
* fixed linting issues again
* refactor: replaced Pending Tasks with alert and made general styling/accesibility updates
Co-authored-by: Maxwell Frank <mfrank@2u.com>
This PR adds delete and edit functionality to emails that are scheduled to be sent at a future date. The workflow for editing is as such:
A user clicks edit on the table
The contents of the email are copied to the editor, and the user makes edits
The user is warned that this is editing an email, and that it will not create a new task, instead updating the selected one
If they accept, the email is updated.
For delete, the user just hits the delete button, and its gone. There is now warning popup as of yet.
This PR also adds the toast component for success and errors when sending emails.
This PR refactors some of the code around the context store to be more in line with the project organization ADR in this repo. Essentially, it splits the reducers and actions into slices used by the components that need them to prevent pollution of data in the store.
This PR also handles most of the refactor around the BulkEmailTool making use of the BulkEmailToolProvider in order to share data between components. This allows for better copyToEditor functionality, amongst other changes, as the email form now handles its state within the context store.
The Provider and its store is purposefully tied to the BulkEmailTool as to prevent any bleeding of state information between tools that may be added to the comms MFE in the future.
This PR also adds the first iteration of the scheduled emails table. This table will allow for viewing, deleting, and editing emails in the future. For now, it only adds viewing. The viewing modal DOES support copy to editor functionality but it is NOT editing the original entry and WILL schedule a new email if submitted.
[MICROBA-1822][CR-4822]
* use `originalUserIsStaff` to gate bulk email tool access over `isStaff`
Additional Context
Access to this tool was originally gated by looking at the `isStaff` value from the CourseMetadata data returned to us from the LMS. The user masquerading feature seems to have some interesting interactions with the Instructor Dashboard and we may be denying legitimate staff/admin/instructors access to the tool. Instead of using the value of `isStaff` we will now use `originalUserIsStaff` to determine if the user accessing the tool should be allowed access (and this follows how the Learning MFE gates content).
This pr extracts out the message modal so that it can be reused
elsewhere in the app. Specifically so we can reuse it for the "view"
button in the scheduled emails table.
Currently, our bulk email tool in concept looks something like this:
- BulkEmailTool
- BulkEmailForm
- BulkEmailTaskManager
Right now, the two components under the parent BulkEmailTool dont really
need to communicate with each other. For scheduled email, these two
components are going to be relying on the same data, and there need to
be provided that data by the parent. In order to make things more
manageable, this PR sets up some boilerplate and patterning for this
data. What this PR will include:
- Documentation around the pattern
- Necessary boilerplate to leverage the context store for the
BulkEmailTool
- Tests around said store
What this PR will not include:
- Changes to the UI or form functionality
This handles a few things around the scheduled email UI. This includes:
1. Adding the schedule email UI date/time picker.
2. Adds states to the submit button for scheduling emails.
3. Drys out intl code and some submitting states.
4. Matches the email form UI to mocks.
This however does not include:
1. A table to show scheduled emails. Scheduled emails at the moment are
displayed in the "pending tasks" section.
2. Matching the tasks section to the mocks.
Course teams were having issues sending bulk emails to themselves and
students. This was caused by two problems.
1. The language selector tool was failing because of no default language
settings in safari is possible
2. The translated string for the "continue" button on the submit modal
was messing with the markup and causing the event to POST the email
to not properly fire.
To fix the language issue for now, we are disabling the language
selector plugin. To fix the markup issue, we are forcing the string to
render in a fragment to remove the additional span, allowing the event
to fire no matter where the user clicks the button.
- Missing left align tool (just a typo)
- Missing advanced image options (missing configuration)
- Page title was never set
Other issues such as email title, google+, and sender address are not
related to the MFE and are quirks to do with the staging environment.
[MICROBA-1743]
* Use `LearningHeader` component which can display the course information (title, org, number) in the header to the learner (matching existing design).
* Refactor components to introduce a `PageContainer` component in order to support displaying course information in header.
* Refactor the BulkEmailTool component to take advantage of the new course metadata context provider.
* Add tests for new `PageContainer` component.
* Fix existing tests due to refactor.
* Add "Email" label above recipient selection checkboxes to match existing design.
Image uploads were broken for 2 reasons on stage:
1. Our bleaching on the server was too strong. it was pulling out
attributes inside of the image tags that allowed base64 encoding to
work properly.
2. The paste_data_images needs to be set to true to allow for dragging
and dropping of images into the editor
Since bleach has been rolled back for now, adding this setting should
allow for images to be properly uploaded.
[MICROBA-1743]
Fixes an issue where we couldn't override the header and footer with the branded versiom within the Comms MFE because some of the dependencies of the branded components are not currently Webpack5 compliant. Adds a rule to make webpack5 less strict with imports that do not include a file extension.
This also includes a change so that the Comms MFE uses the Open edX branded colors/styles by default.
The old tool had a button in the modal used to view past emails that
allowed you to copy the content into the editor. This replicates that
functionality, but without the ability to fill in the subject field of
the email. This was done to keep certain components more seperate.
