The default behavior of the TinyMCE editor is to rewrite links that share the same
domain as the component to be relative to that path. Relative URLs will never work in
email contents, so they _always_ need to be absolute URLs. This adds the configuration
settings for `relative_urls` and `remove_script_host` in TinyMCE to always be false,
enabling it to always use absolute URLs. See
[here](https://www.tiny.cloud/docs/configure/url-handling/) for reference.
frontend-platform supports runtime configuration since 2.5.0 (see the PR
that introduced it[1], but it requires MFE cooperation. This implements
just that: by avoiding making configuration values constant, it should
now be possible to change them after initialization.
Only a single change related to the `LMS_BASE_URL` setting was required.
[1] openedx/frontend-platform#335
* fix: [APER-1936] Changes for a11y review
- Fixes skip nav link to work properly
- inline styles pending tasks link
- adds <main>
- adds sr-only span to "view message" links in task history table
- header/footer updated in seperate PR
* chore: add sr-only span to unit test
* fix: fix space before sr-only span"
* 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.
