#7999 Admin page to really delete projects

v1.3.2
closed
Igor Bondarenko
sf-8 (45) 42cc (432)
General
Dave Brondsema
2015-11-30
2015-10-05
Dave Brondsema
No

Admins should be able to really delete projects, not just soft-delete. (Here's all the things we can do, possibly break out into separate tickets)

  • create admin page with a textarea in which project names or urls can be entered, whitespace separated.
  • ProjectRegistrationProvider should have a method to parse the (nbhd,project) out of each URL, so that custom sites urls can be parsed specially if needed.
  • to actually do the removal, SF can contribute our forge-classic/scripts/purge-project logic. Just need to do a little refactoring:
    • remove find_project_by_unix_name usage, it should work with a (nbhd,project) or such
    • probably good to make it a ScriptTask so it can be run that way too
    • forge-classic script should call the new script
  • fire an event so other custom hooks can do things upon project deletion if needed
  • /nf/admin/new_projects already builds a list of project names at the bottom of the page as you click the checkboxes. Enhance that list of names to link over to to the project deletion form.
  • include a text box for "reason". Log it to disk, and include in the event parameters.
  • have a checkbox for "Disable all project members". It should disable all users that are admins or devs of the project. And add a user audit log comment, noting the related project and the "reason" given.
  • document it in administration.rst

Discussion

  • Dave Brondsema

    Dave Brondsema - 2015-10-05
    • labels: --> sf-current, sf-8
     

  • Igor Bondarenko - 2015-10-26

    If I understood it correctly it is supposed to be site-admin page, right?

     

    • Dave Brondsema

      Dave Brondsema - 2015-10-26

      Yep. Maybe in the future we'd let users delete their own project too, in combination with the allow_project_delete setting somehow.

       

  • Igor Bondarenko - 2015-10-26
    • labels: sf-current, sf-8 --> sf-current, sf-8, 42cc
    • assigned_to: Igor Bondarenko
     

  • Igor Bondarenko - 2015-10-29

    purge-project removes all project's artifacts, solr index, etc, but leaves project document in databases (renames it to 'deleted-<sf-guid>' and sets deleted=True).

    Do we need to keep this behavior in allura task?

    One side-effect of this is that after project.deleted changes to True we fire task to update solr index, which raises an exception, since all project-related stuff is deleted. We can bypass that in Project.should_update_index, though

     

    • Igor Bondarenko - 2015-10-29

      Hm, anyway we can't rely in allura code on the presence of the sf-specific group ids to rename a project... I guess we can just mark project as deleted by default and rename it only in the sf-specific implementation.

       

    • Dave Brondsema

      Dave Brondsema - 2015-10-30

      We could rename to 'deleted-<objectid>' if we want to keep the project doc around. I'm trying to think of why we would need that and I can't think of any reason. The data is available in the offline files if needed for anything. And a stub project record wouldn't even be very useful since it isn't complete.</objectid>

      The restore script (which we should contribute into Allura proper at some point) does check for that stub record and re-use it, but it doesn't need to. It already makes a new Project() if the sub isn't there. So I say we get rid of it.

       

  • Igor Bondarenko - 2015-11-04
    • status: open --> review
     

  • Igor Bondarenko - 2015-11-04

    Closed #854-857. {allura,forge-classic:ib/7999}

     

  • Dave Brondsema

    Dave Brondsema - 2015-11-10

    Looking good. Nice thorough tests too :)

    On the input side, I'd like to see a bit more polish and validation/confirmation:

    • if a submission doesn't parse anything, then the script task is still run but you see various errors in the log ("paster: error: too few arguments")
    • it'd be convienent if a single shortname (no neighborhood) could be entered. Perhaps project_from_url could check that in such a case the project exists only in the /p/ neighborhood - to prevent any accidental matches.
    • placeholder example in the <textarea>
    • adding an extra confirmation step would serve several benefits:
      • one more opportunity to confirm you really want to delete these projects
      • show which projects got parsed, so you know whats being deleted
      • show any lines that failed to parse, so you can fix your inputs if needed
    • the flash message after confirmation is a bit ugly "Delete scheduled for [(u'/p/', u'mech16504788664')]"

    On the task & event side:

    Can you move the purge_project function from the task into a ProjectRegistrationProvider method? This would fit nicely with the delete_project method that's already there. It also will let extensions have full control over what happens and when, during purge. I've realized that the event approach would be too late for some integrations to do what they need to do. With this change, they'll have full control and the event won't even be necessary.

     

  • Dave Brondsema

    Dave Brondsema - 2015-11-10
    • status: review --> in-progress
    • Reviewer: Dave Brondsema
     

  • Igor Bondarenko - 2015-11-18
    • status: in-progress --> review
     

  • Igor Bondarenko - 2015-11-18

    Closed #861. New branch allura:ib/7999a (force push is disabled on apache repos now)

     

  • Dave Brondsema

    Dave Brondsema - 2015-11-23

    Looking really good, just found one issue: parsing of subprojects. Given a URL to a subproject like http://localhost/p/foo/bar/ it parses out the p/foo project only. So there's not a way to delete a subproject. I guess the parsing would have to check the 3rd url component (if there is one) and see if there's a subproject there? Seems a bit ugly but I'm not sure of a better way.

     

  • Dave Brondsema

    Dave Brondsema - 2015-11-23
    • status: review --> in-progress
     

  • Igor Bondarenko - 2015-11-25

    Closed #864. Updated ib/7999a

     

  • Igor Bondarenko - 2015-11-25
    • status: in-progress --> review
     

  • Dave Brondsema

    Dave Brondsema - 2015-11-25
    • status: review --> closed
     

  • Dave Brondsema

    Dave Brondsema - 2015-11-30
    • labels: sf-current, sf-8, 42cc --> sf-8, 42cc
     

  • Dave Brondsema

    Dave Brondsema - 2015-12-08
    • Milestone: unreleased --> v1.3.2
     

Log in to post a comment.