- **status**: review --> in-progress
- **Reviewer**: Dave Brondsema
- **Comment**:
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.
---
** [tickets:#7999] Admin page to really delete projects**
**Status:** in-progress
**Milestone:** unreleased
**Labels:** sf-current sf-8 42cc
**Created:** Mon Oct 05, 2015 02:38 PM UTC by Dave Brondsema
**Last Updated:** Wed Nov 04, 2015 05:21 PM UTC
**Owner:** Igor Bondarenko
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
---
Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed
to https://forge-allura.apache.org/p/allura/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is
a mailing list, you can unsubscribe from the mailing list.
