Excellent progress! This fixes the invite for proposal draft.

It does not seem to fix an initial draft, when e.g. an applicant apply for a lab or content note and begin with saving as draft.

It is a oversight from my side, the latest should work. def0e76

Test are failing, I'll take a deeper look.

After carefully reviewing, I realized that the application auto-advances to the next phase at different phases, and there could be multiple phases it can transition to when the application is at a specific phase, say more info required phase. Therefore, we need an explicit marker to decide:

1. Whether to auto advance or not, if the user submits the application.
2. which target phase to pick when the user submit a application.

The current fix, while functional, has an issue where it will always transition to the first available transition at that Phase.

I think we can solve this we need to update the workflow spec itself, that enables to deterministically know above two:

1. Remove the translation marker, on the "Submit" display name, I believe it's not displayed in the UI anywhere.
2. Introduce a new custom property on the target phase that indicates whether to auto-advance to this phase if the user submits the application at the source phase.

@frjo @wes-otf Any preference on the (1) or (2). My take would be to go for an explicit custom marker, even though it's little verbose, for the shake of clarity.

@theskumar I am not sure about the best approach but what do you think about having a predefined method that can return both types of keys as translated(in same lang) and we can call that method wherever in code we are comparing these keys like here.
Ex:

def translated_keys(post_keys, transition_keys):
    ......
    return translated_post_keys, translated_transition_keys

@theskumar I am not sure about the best approach but what do you think about having a predefined method that can return both types of keys as translated(in same lang) and we can call that method wherever in code we are comparing these keys like here. Ex:

def translated_keys(post_keys, transition_keys):
    ......
    return translated_post_keys, translated_transition_keys

Thank for the input, initial tried getting the untranslated version of the display but it looks by the time it reaches here as a key of the dictionaries, this is already translated, and it make sense as the translated string will be needed for hashing in in the dict.

I'm in a opinion that we should not be doing comparison on the basis of translated strings.

Also, since the post.keys are never marked as translatable, you can't get equivalent translated string reliably.

I think option two is best.

I agree that we should never compare strings that might be translated.

I see no other places but in this form_valid() function that we do this check. Correct?

Progressing when saving a submission should only happen when submitting a draft and when submitting a "More information is needed".

Having something explicit in the workflows for these two statuses would make it more clear what is happening.

I see no other places but in this form_valid() function that we do this check. Correct?

Yes, that's when we check if the "Submit" action is present in the targets and then perform_transition to that phase.

I'll check other places as well, but it doesn't seem it should have been used. (If we are using translated string for comparisons at other places, that would probably be another ticket for us to go over)

For the custom route, I'll need to modify some parts of how the phases and transitions are initialized, but it shouldn't be too complicated. I'll be updating the this PR.

PS: Down the road, we must split this workflow file into different module. I see two Request object defined in the same file, one related to Stage and another for Workflow.

Updated the logic to add new marker in the workflow definition indicating this particular phase to pick when the user submits the application and then auto transition to it.

worked great, really nice work @theskumar!