Closed briri closed 3 weeks ago
A "published" section (or when saved as a draft) is essentially just a snapshot of a Section at a point in time that the parent Template was published (or saved as a draft). Versioned sections are immutable!
sections(templateId: number): Promise<Section[] | PublishedSection[]>
section(sectionId: number): Promise<Section | PublishedSection>
publishedSections(term: string): Promise< PublishedSection[]>
addSection(templateId: number, name: string, copyFromSectionId: number): Promise<Section>
updateSection(sectionId: number, name: string): Promise<Section>
(errors included)removeSection(sectionId: number): Promise<boolean>
@briri Depending on how you see the data being stored but "section display order" might be important when we return the sections for a template
That's a good point @fraserclark. Maybe we could store the order in a TemplateSections table, which we will probably need to map template ids to sections ids.
@briri for the section tags, would it make more sense to create a SectionTags
table, where we include the section id and the tag id rather than having an Int[] array of tags in each section record?
Good points all around. I have updated the definition above.
I don't think we want a TemplateSections join table. A template has sections, but sections do not have templates. When someone selects an existing section from the library to add to their template, we will clone the section and attach that new copy to the template. This allows them to be modified independently within each template.
Thanks @briri. Should I update the above documentation with "displayOrder" and remove "tags" from "Sections" above? Or should we keep the final schema documentation in another location?
Also, Just to double check - a section is unique to just one template and cannot be shared across multiple templates? The reason I am asking is that in the wireframe, I see the below page. If a section can belong to multiple templates, then would it make sense to have a TemplateSections table?
Also, in the "previously created sections", are the sections listed just the ones that the user created before, or ones that were used by Funder or org? I'm trying to figure out how we will associate the sections with the user or funder/org.
@briri are we excluding "Section guidance" field? I can't remember. The wireframe includes it (see below), so if we need it we should add a "guidance" field to "Section" above.
I updated the definition above with those changes.
I don't think it's a good idea to have a single section belong to multiple templates (at least from a database perspective). Unless I am misunderstanding the way sections will work in the redesigned system. This is my understanding of how they work (note that this is clouded by how it currently works 🙃):
@briri I see what you are saying. So when a user selects an existing section for a new template, do we create a separate section id based off of the info from the existing template?
@briri @jupiter007
I have always assumed the previously created sections are "locked in time" - an exact clone of that section, at the time of creation - zero linking or push/pulling of content. So whatever the sections content (that is published) of the template you are "duplicating it from"
This applies to the DMP best practice sections too, they are only a starter kit, once you have selected the section, you have full ownership of it.
So, in your example where you add a new question to Roles and Responsibilities for template 3, you would need to go back and update template 1 and template 2 with your new question.
However, it does bring up an interesting thought, which was never fully decided/thought through.
If you have 3 templates, you might have 3 "Roles and Responsibilities" in your "previously created sections" listed and it is hard to determine which one belongs to which previously created template.
I'd be reluctant in this "phase" of work to allow them to manage their "library of previous created sections” as it's a nice-to-have and we have more important things to work on.
I’d suggest we just add some text to suggest the "template" it is 'associated' with
Yes 💯 we can just include the title to help them select the correct section from the library.
@jupiter007 yes, we would have a new id for the "copied" section. The MySQL DB uses an auto-increment number, so it will handle id assignment.
I think it makes sense to let the backend handle tasks like copying/cloning a section/template/question. We could have a GraphQL mutation called cloneSection(newTemplateId: number, sectionToCloneId: number, displayPosition: number): Section
Then the backend would copy the original section, attach the new templateId to it, change the name to Copy of ...
, set the created timestamp and the createdById from the JWT, etc. Then save it which would assign an id, and return it to the front end.
We need to review the wireframes related to Template Sections and define the initial schema, queries and logic that the backend will need to provide.
Related to #33