Handle attempts to change the access policy for a project under embargo to open

[briangow]

Currently if a project is under embargo and an editor or author attempts to switch the access policy for the project to open during publication, we do not do any checks to prevent this or report an error.

In #1744 we indicate that there is a way to get access to files from open access projects without going through Django. Because of this, in #1740 we chose not to allow files in open access projects to be placed under embargo. The embargo would be meaningless if there was a way around it.

In #1758 we indicate that it is not possible to change a project from credentialed / restricted to restricted / open. This is unrelated to whether a projects files are under embargo.

Given this we need to do either a. or b.:

a. Implement a fix for #1758. When a project is under embargo and an attempt to switch the project's access policy to open is made, we need to either:

• prevent the user from switching by issuing a message such as "A project with files under embargo cannot be set as an open access project".

or

• reset embargo_files_days to None, accept the request to switch the project to open, and display a message that indicates "The embargo on this project's files has been removed since it can not be set for an open access project"

b. Implement a fix for #1758. Implement a fix for #1744 which only allows users to go through Django to get to the files in open access projects. We can then remove the restriction that a project under embargo cannot be open access. In this case we do not need to add any new code related to access for projects under embargo. Regardless of whether a project is under embargo or not it will be possible to switch between open, restricted, and credentialed during the publication process.

[briangow]

Please see #2076 for additional information around what will happen if a project is changed from restricted/credentialed with an embargo to open.

[briangow]

Eventually we want to be able to embargo an open access project, as described in b. above. Until that is implemented, we want to prevent an embargo from being applied to an open access project.

As discussed in #2076 , given the current state of the code we could prevent an embargo from being applied to a project that is switched to open access if we simply do not carry the embargo forward for new project versions. In a discussion with @tompollard , we agreed that this is the desirable behavior, regardless of this issue. Therefore, the editor would have to explicitly set the embargo for a new version of a project. If there is agreement on that, I will look into making this change. This will solve the short term problem by preventing an embargo from being accidentally applied to an open access project.

We should leave this issue open (or create a new issue) until we come up with a solution for how to allow an embargo on an open access project.