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:
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
If I understood it correctly it is supposed to be site-admin page, right?
Yep. Maybe in the future we'd let users delete their own project too, in combination with the
purge-projectremoves 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
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.
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.
Looking good. Nice thorough tests too :)
On the input side, I'd like to see a bit more polish and validation/confirmation:
project_from_urlcould check that in such a case the project exists only in the
/p/neighborhood - to prevent any accidental matches.
"Delete scheduled for [(u'/p/', u'mech16504788664')]"
On the task & event side:
Can you move the
purge_projectfunction from the task into a
ProjectRegistrationProvidermethod? This would fit nicely with the
delete_projectmethod 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.
Closed #861. New branch
allura:ib/7999a(force push is disabled on apache repos now)
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.
Closed #864. Updated