Skip to content

Contract registration

Course editions should have a section to require a contract. Students and companies should enter personal details. This should be tied in with the group approval logic (preferably using callbacks).

Contracts should be a separate entity (i.e. not part of group membership, but with a relation to it) so that they are never deleted. Access control should be considered.

Companies already sign a contract - basically a tickbox saying I'm a good company. We now want a standard agreement. If a company uses the standard contract then it can be done digitally in PF.

Workflow:

  1. Group applies (enters locked state)
  2. Group is client approved - in the modal, the company reviews the contract template and enters/edits information. Contracts are generated.
  3. Students sign. After all students sign, company receives a notification.
  4. Company signs each contract individually
  5. Coordinator signs contracts and then approves group
  • All coordinator-supplied data is stored in a CourseContractTemplate entity with a one-to-one relation to CourseEdition. - @mmladenov
    • All coordinator-supplied fields are present in this entity.
    • This should have the same logic as the CourseConfiguration relation
    • This should be a new section on the CourseEdition editing page.
  • Company-supplied fields are part of Project. They are optional and entered by the company while proposing the project (if the course edition has the contract feature enabled). - @mmladenov
    • Project views should be updated to show these fields.
    • In the student view, these fields should be hidden if empty.
    • Part of the project approval workflow (i.e. can't be changed without the coordinator knowing) - thus, not a template, but part of the Project model
  • Contract signing - partial that can be reused in multiple places - @rstular
    • There should be a checkbox for "I have read the contract above"
    • The PNG gets stored in the database via an upload endpoint
  • DraftContract entity (or IncompleteContract, or ContractInProgress, or similar) - @akalandadze
    • one for every student
    • columns for all fields of the contract
    • files for the signatures of all parties
    • associations are nullable such that that it isn't deleted if one of the associated entities disappears
  • DraftContract is created when group is client-approved - @rstular
    • data is copied from the templates when the DraftContract is created
    • DraftContract.from(project)
      • copies data from the templates (fields in project and fields in project.course_edition.contract_template, the rest of the fields are null since they will be specified by the student later)
      • can be done via reflection (probably?)
      • The last approved version of the project should be used when making contracts
      • If draft contracts already exist (e.g. if a group has been rolled back to a previous state), reuse these, don't generate new ones. Do not update the existing ones.
  • There should be a method to render a PDF from a DraftContract - @akalandadze
    • Server-side generation
    • Look into how MARE does it
  • Contract entity - @akalandadze
    • only has a file, no raw data
    • created automatically when a DraftContract is fully signed
    • DraftContract and associated data (signatures) is then deleted
    • should never be removed, i.e. associations are nullable
    • Should be linked to User (student), Offerer, Group, Project (?), Course Edition (to make them still accessible if some entities, e.g. Group, are removed)
  • Make all contract-related fields read-only as soon as anyone has signed - e.g. validation that runs only on update
  • No edits to the CourseContractTemplate are allowed when at least one downstream DraftContract or Contract exists
  • No edits to the ProjectContractTemplate are allowed when at least one downstream DraftContract or Contract exists
  • Make signing possible for coordinators - @rstular
  • signing_status method on Group - @rstular
    • queries memberships and contracts
    • possible values: not_signed, students_signed, offerer_signed, signed
    • no new states are introduced, contract signing happens when the group is Approved (Locked) + Client approved
  • Partial for viewing and editing contract - @akalandadze
    • Should be easy to use in different contexts (student, company, coordinator, for both rendering and editing).
    • HTML that looks close to the real contract (i.e. identical text)
    • Some fields should be editable (inline), this set of fields changes based on stage. Controlled by a parameter passed to the partial.
  • Integrate contract signing with the group approval workflow
    • Add the new stages
    • Use callbacks for switching between stages (where possible)
    • When making an offer, it should be made clear to the company in the UI that edits to the project contract template need to be approved before the contract is offered
  • Disallow making an offer if there's a pending edit (in general, not only when contracts exist)
    • ...
  • Validation: it should be impossible for a group to enter approved status without fully signed signing_status - @rstular
  • There should be a button on the coordinator's side to delete all draft contracts and reset the group's state. Only available if there are no full contracts; fully-signed contracts are never deleted and such groups cannot be reset.
    • Think about draft contracts signed by two parties (student + company), perhaps we should disassociate them from the group but still keep them?
      • What if a client signs contracts but then revokes an offer?
  • Validation: it should be impossible to add more members after client approval (?)
    • To be discussed
    • If we do this, we need to generate more contracts on demand
  • Notifications
    • Coordinator should not get a notification on client approval if contracts are enabled
    • Students get a notification when they need to sign
    • Company gets a notification after all students sign
    • Coordinator gets a notification after company signs all contracts
  • 3 parties - uni, student, company
  • a checkbox or button, no uploading
  • name, email, date of birth, address
  • New stage: "students signing contracts": after the group accepts the offer, all students sign. Contract objects are generated via a callback when the group enters this stage.
  • New stage: after all students sign, "company signing contracts", company has to sign
  • Coordinator signs on behalf of the uni when approving the group
  • Rails model validation should be used such that it's impossible to approve a group for a project if any of the contracts isn't signed or a contract object isn't present
  • we can let users draw on the screen to sign (Thomas will check if it's necessary; probably unnecessary)
  • each student gets an individual contract; each student must sign (i.e. not just the group leader)
  • company and uni sign all 5 at once (e.g. clicking "sign" next to each of them, on the same page)
  • Details are specified when signing the contract (we may query some details from SSO or LDAP, currently the display name is not necessarily a legal name)
  • before signing, show empty pdf with fields for name etc and then fill them out after signing
  • Internal projects don't require contract. Each project should have a "contract on PF" checkbox, defaults to on for external projects (external offerer). It can be disabled by the coordinator if e.g. the project requires a custom contract. Custom contracts are handled externally.
  • contracts need to have relations nullable so that they never get deleted even if a group is deleted; this means some information will have to be duplicated
  • fully signed contracts must always be shown to all parties even if the student later leaves a group
Edited by Martin Mladenov