List of cycles to which the proposal has been submitted

[DJWalker42]

Actually, the first problem is that the "submitted status" of a proposal is not updated to true in the 'submitProposal' API call; the clone gets updated, but not the original proposal.

After adding the code to set the submitted status to true in the API, and once the proposal is submitted, you are taken back to the overview page for the proposal and the submitted status now correctly reads "yes". However, this page is short-lived. As soon as you navigate away there is no way to get back to that overview page (bar the back button on your browser).

The landing page probably needs to display both non-submitted and submitted proposals, and clicking on any proposal takes you to its overview page. As a submitted proposal is non-editable it shouldn't show up in the lefthand navigation bar but the overview page of it would be useful.

We need some means of listing the Cycles to which a proposal has been submitted. Currently, from the API, we can get all submitted proposals to a particular cycle only, rather than query by investigator. A query needs to be added to the 'getSubmittedProposals' API call such that we can filter submitted proposals by investigator/user. Once that is done, then here we can implement this for the frontend.

[pahjbo]

The intention is the the original is not set to submitted - remember that you can potentially submit the same proposal to several telescopes, so you want it there ready to submit to the next - To see submitted proposals then the explicit SubmittedProposal objects should be queried. That is also why the original is cloned.

[DJWalker42]

Ah okay. In terms of current user experience, once a proposal is submitted the user is taken back to the 'Overview' page of their proposal. The 'submitted' status is found at the bottom of that page, and it will read "No", and in fact it will always read "No". This will be confusing for the user.

Therefore, it would be better for the "submitted status" to be a list of cycles to which the proposal has been submitted, or empty if not yet submitted to any. Either that comes through as a model change to the proposal; submitted status updated from boolean to list of strings, or as an additional member, or we can try to extract it from the management model.

[pahjbo]

There really needs to be a separate table (outside the model), that records which original proposal IDs get submitted to which cycles.. The submitted status was put into the model as a quick hack, so that the submitted proposals did not appear, but perhaps this is a case where it would be better if the submitted proposal were actually a sub-class!

The alternative is that the "related proposals" part of the model could be used - though this was originally envisioned to point to less close relationships than just submitted.