Decide on a project slug before publication time

[bemoody]

When a newly-created project is published, the editor is asked, at the very last possible moment, to choose a permanent public name (slug) for the project.

I dislike this and have wanted to fix it for a long time. For authors, the permanent URL shouldn't be a surprise. For editors, it'd be nice to have some coordination amongst the team on naming conventions, and to be able to check for typos. From the technical side, we may want to be able to prepare cloud resources (or even local resources, such as zip files) in advance of publication. Also we'd like to catch any technical errors in advance (issue #1401).

So here's what I'd do instead:

• Add a slug field (null=True, unique=True) to the CoreProject.

• When a project is accepted, if the CoreProject slug is null, prompt the editor to enter a slug.

• When a project is archived, if the CoreProject has no published versions, then its slug should be reset to null.

• After a project has been accepted and not published, if the CoreProject has no published versions, the editor may change the slug.

• When the project is published, the new PublishedProject slug is copied directly from its CoreProject slug. (If the CoreProject slug is null, the project is not publishable.)

Eventually, we might also drop the slug field from the PublishedProject model.

[tompollard]

When a project is accepted, if the CoreProject slug is null, prompt the editor to enter a slug.

I agree that it would be nice to have the slug earlier in the process. Your suggested workflow makes sense to me.

After a project has been accepted and not published, if the CoreProject has no published versions, the editor may change the slug.

We lose some of the value of an early-defined slug if it might change later, but I agree that having the flexibility to change up until publication is needed.