Feature #10334

User deletion CLI tool

Added by Mike Cantelon about 4 years ago. Updated about 3 years ago.

Status:VerifiedStart date:09/21/2016
Priority:MediumDue date:
Assignee:-% Done:

0%

Category:CLI tools
Target version:Release 2.4.0
Google Code Legacy ID: Tested version:
Sponsored:No Requires documentation:

Description

Add tool for deleting users, with confirmation (that can be overrided with "--force" option) and check to make sure user isn't the only superuser.

History

#1 Updated by Mike Cantelon about 4 years ago

  • Status changed from In progress to Code Review
  • Assignee changed from Mike Cantelon to Nick Wilkinson

#2 Updated by Mike Cantelon about 4 years ago

  • Requires documentation set to Yes

#3 Updated by Nick Wilkinson about 4 years ago

  • Assignee changed from Nick Wilkinson to Mike Gale

#4 Updated by Mike Gale about 4 years ago

  • Assignee changed from Mike Gale to Mike Cantelon

looks good, I just had one suggestion (which is really just a personal preference, feel free to ignore)

#5 Updated by Mike Cantelon about 4 years ago

  • Status changed from Code Review to QA/Review
  • Assignee changed from Mike Cantelon to Nick Wilkinson

#6 Updated by Nick Wilkinson about 4 years ago

  • Assignee changed from Nick Wilkinson to Sara Allain

#7 Updated by Nick Wilkinson about 4 years ago

  • Assignee changed from Sara Allain to Mike Cantelon

Hi Mike, can you post some testing instructions? You could just run the help command for the task and paste the output here.

#8 Updated by Mike Cantelon about 4 years ago

  • Assignee changed from Mike Cantelon to Nick Wilkinson

Some tests that could be done:

1) ./symfony tools:delete-user <non-administrator username that doesn't exist> (should be asked to confirm, then get an error)

2) ./symfony tools:delete-user <non-administrator username that exists> (after entering "y" to confirm should get deleted)

3) ./symfony tools:delete-user <non-administrator username that exists> --force (there should be no confirmation request and should get deleted)

4) ./symfony tools:delete-user <sole administrator username that exists> (it should error after asking confirmation, not letting the last administrator be deleted)

5) ./symfony tools:delete-user <one of more than one administrator usernames that exist> (it should ask confirmation then delete)

6) ./symfony tools:delete-user <username that exists and has associated notes> (it should error complaining that note association's would be lost)

7) ./symfony tools:delete-user <username that exists and has associated notes> --update-notes (it should delete the user despite the note associations)

Usage:
 symfony tools:delete-user [--application[="..."]] [--env="..."] [--connection="..."] [-f|--force] [-n|--update-notes] username

Arguments:
 username        The username to delete.

Options:
 --application   The application name (default: 1)
 --env           The environment (default: cli)
 --connection    The connection name (default: propel)
 --force         (-f) Delete without confirmation
 --update-notes  (-n) Dissassociate any notes the user has created

#9 Updated by Nick Wilkinson about 4 years ago

  • Assignee changed from Nick Wilkinson to Sara Allain

Hi Sara, can you go through Mike's test examples for QA?

#10 Updated by Sara Allain about 4 years ago

Everything checks out so far, but I'm having trouble reproducing the condition for the last two examples through the UI (associating a note with a user). Should be as described in: https://projects.artefactual.com/issues/4812. Leaving this here to come back to later :)

#11 Updated by Sara Allain about 4 years ago

  • Status changed from QA/Review to Verified

As per this: https://projects.artefactual.com/issues/4812#note-6, notes are disassociated from the user that created them if the user is going to be deleted. After running this:

./symfony tools:delete-user <username that exists and has associated notes>

the user is deleted, but the note remains. No warning is given that the user has a note because the note is disassociated when the deletion process kicks off. I think this is acceptable behaviour, so marking this verified.

Note: there's a recommendation to amend the note-disassociating behaviour in the aforementioned ticket.

#12 Updated by Dan Gillean about 3 years ago

  • Assignee deleted (Sara Allain)
  • Requires documentation deleted (Yes)

Also available in: Atom PDF