Make Create Project Flow descriptions configurable

[matkaczmarek]

T-CAIREM 1137

We should make copies on create project flow easy to manage and change:

[tompollard]

Thanks @matkaczmarek please could you include a full description for the pull request here? I don't think we have access to your issue tracker (or at least if we do, not all of us are using it!).

[matkaczmarek]

Thanks @matkaczmarek please could you include a full description for the pull request here? I don't think we have access to your issue tracker (or at least if we do, not all of us are using it!).

Hi @tompollard I updated the description but keep in mind that this is just a proof of concept and still in WIP state. We will discuss the general approach to this feature with @Rutvikrj26 on Tuesday but I created this draft to demonstrate one of the potential approaches.

[matkaczmarek]

Two questions for @tompollard, @bemoody:

• should we implement defaults in views when step details is not available in database such as here(if/else): https://github.com/MIT-LCP/physionet-build/pull/2198/files#diff-4f961161fbbb6291c7505b39816715a53c104e67e49f1d9e90e5e78f5854ea23R40
• class Section and class StepDetails are very similar, I introduced AbstractSection class but maybe it is overengineering: https://github.com/MIT-LCP/physionet-build/pull/2198/files#diff-5f08ef366490f7ccf136e57d79e24e97eaca87f08b8a86e89edd678d6324b763R62

Also I'm not very fond of naming those new class as Step/StepDetails, maybe you have better idea?

[bemoody]

(I haven't looked at the code at all, just responding to things we talked about in the meeting.)

should we implement defaults in views when step details is not available in database such as here

Not a great idea for a couple of reasons:

• We don't want logic in the template files (as much as we can possibly avoid it.)

• It's better not to have two different data flows to begin with (in this case, the "default" text being stored in a secondary template file, versus the "custom" text being stored in the database.)

A better approach is to move the default text into the database (using a data migration.)

class Section and class StepDetails are very similar, I introduced AbstractSection class but maybe it is overengineering

Yeah, these don't really belong together and trying to use an abstract class makes things needlessly complicated in my opinion.

Also I'm not very fond of naming those new class as Step/StepDetails, maybe you have better idea?

Words that come to mind: "form description", "help text", "boilerplate"?

I think that we would probably like to reuse the same model for things across the site that are not necessarily tied to the project-submission-workflow pages (for example, the user settings pages.)

[Rutvikrj26]

I've completed the implementation started by @matkaczmarek with most of the feedback incorporated by @bemoody. However, I could not come up with a better name and have kept it the same. [Further work on fixing tests pending]

@bemoody I do have the fixtures, but need some help with incorporating the fixtures (project_copy.json) in the physionet/fixtures into the migrations at the start of the deployment. Please let me know how would you like that to be implemented for physionet.

[Rutvikrj26]

@bemoody I have re-generated the migrations as you suggested and it has resolved the issue. The PR is now open for review.

Further, this would require data seeding to put into the database at the start of the deployment right after table migrations. Are there any ways that you suggest we implement for that?

[bemoody]

I keep coming back to thinking about translation, because the problem you're trying to solve here is very nearly the same problem that GNU gettext, and other i18n libraries, are meant to solve. If you haven't ever used gettext, you should read about it and understand how it works and why.

One of the distinguishing features of the GNU approach is that the message-ID is the same as the "untranslated" string (i.e., English is treated as the default.) This is a bit controversial; a competing philosophy says that message-ID should be a fixed identifier of some kind, and English should be treated the same as any other language.

But either approach recognizes that the messages are separate from the application logic, and they may evolve separately.

Suppose, for the sake of argument, that we wanted to move the Ethics Statement into the Content page, while moving the Supporting Documents to a new page after the Files page.

Then, suddenly, the former description for the Ethics page might or might not make any sense; not to mention, the order of "steps" wouldn't match what's in the database. As developers implementing this change, we would need to define a new set of defaults, while also trying to preserve existing customizations. That's, in essence, the problem that tools like xgettext/msgmerge are designed to solve.

I don't have a completely fleshed out idea here, but hopefully this is some food for thought.