Closed jsperhac closed 4 months ago
Check if the original spec requires a campaign secret expiration. If it's in the spec, please add, if not... think about adding it if it's easy, add it. If you have questions about scope.
Other tasks TODO discussed in code walkthrough:
Done:
Let me think on this a bit. I originally wanted campaigns to just be a type of newsletter and appear under the newsletter heading and not be a seperate view. This makes the disconnect between campaigns and the rest of the component a little more glaring. I just need to think on it a bit then will probably be fine.
Code changes needed, as discussed in code walkthrough:
* add csrf tokens into the form * add ability to delete a Campaign * check if adding a campaign expiration date is in the spec (if so, add it) * verify we are saving the campaign date as UTC (VERIFIED!)
In dev meeting we identified some changes to make here. These have been done in revisions to this branch (NCN-618):
The edited landing page now includes the campaign expiration date, the delete button (trash can):
Further information about the recent changes made to this PR in response to feedback from dev meeting.
The form used to edit the campaign now includes the expiration date and access to the Help page for the feature.
The expiration date defaults to 90 days from the current date. It enables the user to edit this default. The date is saved as UTC and displayed to the user as local time.
The Help pages include descriptions of the changed/added features:
@nkissebe and @dbenham: Changes to this PR (admin-side UI for managing Hub campaign and its secret) were requested in dev meeting and entered in Jira as card NCN-618. These changes should be ready for review.
Superceded by #1704
Dependencies
This work is part of Epic NCN-434, whose PRs should all be deployed together:
1693, NCN-633
plgUserHubzero
(on user login, ensure user has a secret in the DB)1683 NCN-439
com_members
(manage user secret)1676 NCN-437
com_newsletter
(manage campaign secret)1675 NCN-438
com_config
(manage hub secret)1695 NCN-702, NCN-440:
com_newsletter
(update access verification)Summary
As part of the Nanohub Epic NCN-434 we will create and maintain individual Campaign secrets (each secret consists of 32 random characters). This PR provides an interface for the Admin user to manage Campaigns, and reset their secrets, if needed.
The Campaign landing page with example records is shown below:
Development
This development was undertaken for Nanohub, as part of the Epic NCN-434, "Salesforce Newsletter Expiration Token Rewrite".
Epic NCN-434
Motivation
The goal of this work is to enable the admin user to manage and reset secrets associated with individual Campaigns. Campaigns might be created for single-click access to secure Hub pages. The campaign information, including the name and description, the secret, the date created, the modification and expiration dates, and the modifying user, is stored in a database table named
campaign
. This Campaign secret can be hashed together with a user's unique secret and a secret unique to the Hub to create a unique code. This code can be used to form a URL that will be emailed to the user (as part of an email campaign) to provide them with access to a Hub newsletter or other resource, without requiring user login. This is general enough functionality to justify its inclusion in core.Note that resetting the Campaign secret will invalidate any mailings that have utilized it in a hash.
The reasoning for locating this secret-and-hash functionality entirely in the Hub database is that it fulfills needs of the target client, Nanohub. Nanohub uses the third-party software Salesforce, in conjunction with user, usage, and Hub data duplicated from the Nanohub back-end database, to generate and send email campaign and newsletters. Their duplications of the campaign, Hub, and user secrets will enable them to send email campaigns in their preferred way.
Code Description
The Hub Campaign management UI was built into the
com_newsletter
component. Campaign management is manifested as a tab in the Newsletter component. It's present only on the administrator interface. Though these new Campaigns have nothing to do with Hubzero Newsletters, they could be used together in the future.In this PR, the Newsletter component is expanded to add a tab for Campaign management. This interface enables the admin user to create and save a name and description with which the secret (not shown in the interface) is associated. The user has the option to edit an existing Campaign to reset its secret.
Architecturally, the present work required creation of an admin controller, display and edit views, a help page, a migration file, and a model for the Campaign.
A new help file describing the use and purpose of Campaigns is linked from the Campaign landing page in the Newsletter component. A migration file is also included. This file creates the required
campaign
database table, on up migration; it drops the table on down migration.Testing
This feature was tested by creating, editing, and viewing Campaigns using the Admin site's Newsletter component, and by viewing the
campaign
database table to verify when secrets are regenerated.Up and down migration was also tested successfully, as follows:
down: php muse migration --file=Migration20230920000000ComNewsletter.php -d=down -f On down migration, this script drops the
campaign
tableup: php muse migration --file=Migration20230920000000ComNewsletter.php -d=up -f On up migration it recreates the table.
The admin user can edit an individual campaign and optionally reset its secret. Only the secret selected should be updated (this was verified in dev testing). All changes to the title, description, modifying user, and timestamps should be correct (also verified in dev testing).
Queries against the
campaign
table were also used during dev testing to ensure that the secret is changed when prompted:Deployment
This PR should be deployed alongside other PRs stemming from Nanohub Epic [NCN-434]. No hotfixes should be needed.
Revisions
This work was revised as part of NCN-618 to include: