Change Project Type Form

[Pezmc]

Description

Implements changing of project types as a "danger" action (this section likely to be renamed in future).

When a user changes project type, the project is suspended, reconfigured, then resumed.

Technically, this uses the same form as the create project form, with some tweaks in behaviour such as hiding the template fields.

UI After UX Review

See comment thread for details.

Original UI from PR

Related Issue(s)

#595

Checklist

• I have read the contribution guidelines
• Suitable unit/system level tests have been added and they pass

Requirements

• Extract shared logic between create/update/copy into a single component
• During edit only permit the Confirm Changes when changes to the project have been made (i.e. dirty form)
• Do not permit template to be updated
• In the UI combine update stack and update project type
• E2E test coverage of updating a projects stack or type
• E2E test coverage of creating and copying projects (previously untested)

[joepavitt]

@Pezmc just flagging a conflict, fairly sure we want what you have, but wanted to make sure as it's likely linked to the moving of the "you have credit" message

[knolleary]

This end point is somewhat overloaded, but it does already let you set the ProjectType of the project only if the project doesn't already have a ProjectType set. This was added when we introduced ProjectTypes as a one-off task for users to set the type of their project. This is why the handling for that will bail out early if the Project already has a ProjectType set.

I'm wondering if, rather than introduce a changeProjectType flag when we don't have equivalents for the other things you can change, this logic should be moved down to the existing handling when body.projectType is set (line 434 of the proposed changes).

That block then has two branches - one for setting ProjectType initially, and one for changing ProjectType.

We should look at the data on production, but handling projects without a ProjectType is very much a legacy edge case that would only apply to FF instances that have been running since before ProjectTypes were introduced.

[Steve-Mcl]

I'm wondering if, rather than introduce a changeProjectType flag when we don't have equivalents for the other things you can change, this logic should be moved down to the existing handling when body.projectType is set (line 434 of the proposed changes).

Essentially, there was the original "no project type" code that was rather implicit in the fact that if body supplied a projectType.

With the introduction of Change Project Type, the body needs to contain both projectType AND stack in the body - so the explicit changeProjectType was introduced to make this 100% explicit as to intention rather than inferring intention from values in body. It is much more deliberate than being present or not.

Also, since the first part of the logic would capture execution (because body.stack is needed in a project type change) we would have to have some if (stack && !projectType) logic in the first part of the handler (i.e. less explicit intention)

[Pezmc]

I've resolved the conflict with main from #1613 and made a couple of minor tweaks to make the endpoint easier to follow.

I'm going to re-work that method in a follow up PR as it's become incredibly overloaded.

[knolleary]

Can you summarize the public API changes this is making? (ie to the /api/v1/projects/... end point) I appreciate its an overloaded endpoint already, so it would be good to get something written down to outline what is being changed.

[Pezmc]

@knolleary The only API change is adding a new flag changeProjectDefinition to the /api/v1/projects endpoint, which triggers a new path in the code (to be refactored away in follow up). When that flag is set, both projectType and stack are required, and the projects type and stack are changed, with a project restart in-between.

[Pezmc]

For reference, the refactored method can be found in https://github.com/flowforge/flowforge/blob/125a4ba5d556797e37b0c6b6f6f8d604723c179c/forge/routes/api/project.js#L346-L595

[knolleary]

Having tried this out, I see you've combined changing stack and changing type into one option.

Updating the stack is a far more routine maintenance action on the project than changing the type. That said, we did introduce versioning of stacks - and if there is a new version of the existing stack available, they get an 'Update Stack' button which gives them a one-click update without having to make any choices:

For the new button 'Change Project Settings' doesn't feel like the right text. As we discussed in slack, Project Settings means something else here. How about just labelling it as Change Project Type as that is what it's for.

[Steve-Mcl]

Updating the stack is a far more routine maintenance action on the project than changing the type. That said, we did introduce versioning of stacks - and if there is a new version of the existing stack available, they get an 'Update Stack' button which gives them a one-click update without having to make any choices

Hi @knolleary not sure if you are asking if the "Update Stack" is now part of the "Change Project Type" or if you are answering a previous question - but for reference, the "Update Stack" button is still there on the form: https://github.com/flowforge/flowforge/pull/1610/files#diff-a5605eb4d14a272712bacb8569e913d4c3f1885a374d594f77277d7d91d2656bR20-R29

Apologies if I am misreading.

[knolleary]

ot sure if you are asking if the "Update Stack" is now part of the "Change Project Type" or if you are answering a previous question - but for reference, the "Update Stack" button is still there on the form:

I appreciate my comment is a little muddled because I changed tack half way through writing it.

My original point is the 'Change Stack' button has been replaced by this new 'Change Project Settings' button

This means changing a project's stack now forces the user through billing considerations, whereas it is only when they change the type will anything need to change with their billing.

[Steve-Mcl]

My original point is the 'Change Stack' button has been replaced by this new 'Change Project Settings' button

This means changing a project's stack now forces the user through billing considerations, whereas it is only when they change the type will anything need to change with their billing.

@knolleary

In my initial work, the change of stack did not show any change of billing. The whole section around billing was totally hidden unless the project type was being changed. I have yet to work through all the changes but I assume that is still the case. I will update you on what I find

[Pezmc]

@knolleary I've addressed the comments from our call earlier this morning and this PR is ready for re-review

Danger Screen

• Restored the change stack option
• Moved the change project option further down as it's a less common operation

Change Project Page

• Charges table hidden when there are only changes to stack

• UI tweaks to improve look of form

Screenshots updated in description