Skip to content

Added new Cypress route to delete TC data by user_id #2483

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

whabanks
Copy link
Contributor

Summary | Résumé

This PR introduces a new Cypress endpoint for cleaning up template categories by user_id and pairs with this admin PR

Test instructions | Instructions pour tester la modification

CI passes, once merged

Release Instructions | Instructions pour le déploiement

None.

Reviewer checklist | Liste de vérification du réviseur

  • This PR does not break existing functionality.
  • This PR does not violate GCNotify's privacy policies.
  • This PR does not raise new security concerns. Refer to our GC Notify Risk Register document on our Google drive.
  • This PR does not significantly alter performance.
  • Additional required documentation resulting of these changes is covered (such as the README, setup instructions, a related ADR or the technical documentation).

⚠ If boxes cannot be checked off before merging the PR, they should be moved to the "Release Instructions" section with appropriate steps required to verify before release. For example, changes to celery code may require tests on staging to verify that performance has not been affected.

@whabanks whabanks requested review from smcmurtry and andrewleith and removed request for smcmurtry March 24, 2025 18:31
whabanks and others added 2 commits March 24, 2025 15:04
- rate_limit_db_calls is expecting data to flow through args not kwargs, adjusted the test to not use kwargs
@@ -64,7 +64,7 @@ def test_expire_api_key_should_update_the_api_key_and_create_history_record(noti

def test_last_used_should_update_the_api_key_and_not_create_history_record(notify_api, sample_api_key):
last_used = datetime.utcnow()
update_last_used_api_key(api_key_id=sample_api_key.id, last_used=last_used)
update_last_used_api_key(sample_api_key.id, last_used)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The rate_limit_db_calls decorator is expecting params through args not kwargs so I adjusted the test here to not use kwargs instead of refactoring the decorator to check both.

Copy link
Contributor

@smcmurtry smcmurtry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm having trouble getting cypress to work locally so maybe I am not the best person to review this.

One more general thought though - have we considered getting cypress to spin up a test database like we use with our unit tests? Writing new endpoints just to delete test data seems like a lot of work.

@@ -169,6 +176,50 @@ def _destroy_test_user(email_name):
db.session.rollback()


@cypress_blueprint.route("/template-categories/cleanup/<user_id>", methods=["POST"])
@fetch_cypress_user_by_id
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it seems a bit unnecessarily complicated to use a decorator to get the user here - why not just get it inside the delete_template_categories_by_user_id function?

Copy link
Contributor Author

@whabanks whabanks Mar 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we write more endpoints to clean up entities by user_id we'll need to fetch and check the user each time. I figured instead of repeating that chunk of code in each method we could just decorate it and not worry about that detail in the future.

Alternatively we could write it as a normal method and just do user = get_user_by_id(user_id) happy to refactor if that seems simpler

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I think that would be simpler but I will leave it up to you

@@ -169,6 +176,50 @@ def _destroy_test_user(email_name):
db.session.rollback()


@cypress_blueprint.route("/template-categories/cleanup/<user_id>", methods=["POST"])
@fetch_cypress_user_by_id
def delete_template_categories_by_user_id(user_id, user):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will anything bad happen if there are still templates in the db that reference a template category we are deleting? Should this function include a check that there are no templates associated with the categories we are deleting?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes! great question here. When we built template categories I wrote the delete method with a cascade parameter for this very purpose (testing specifically). From the method doc:

Deletes a `TemplateCategory`. By default, if the `TemplateCategory` is associated with any `Template`, it will not be deleted.
    If the `cascade` option is specified then the category will be forcible removed:
    1. The `Category` will be dissociated from templates that use it
    2. The `Template` is assigned to one of the default categories that matches the priority of the deleted category
    3. Finally the `Category` will be deleted

@andrewleith
Copy link
Member

I'm having trouble getting cypress to work locally so maybe I am not the best person to review this.

One more general thought though - have we considered getting cypress to spin up a test database like we use with our unit tests? Writing new endpoints just to delete test data seems like a lot of work.

Yes, we did discuss it, and I'm not sure that we've ruled it out.

I keep coming back to how nice and clean the unit tests are, in that they spin up their own temporary DB and then just kill it entirely when finished. Certainly a lot easier to do when you aren't trying to do an end-to-end test...

If we could do this this it would mean the cypress tests in the PR would no longer run against staging, and instead they would run against an entire environment created inside github action runners (db, redis, api, and admin all inside github)

I did experiment with this concept awhile back when trying to get cypress tests integrated into API, but it only included db+redis+api:
#1955

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants