Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
D
Developer Documentation
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 74
    • Issues 74
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 1
    • Merge Requests 1
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Package Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Documentation
  • Docs
  • Developer Documentation
  • Issues
  • #659

Closed
Open
Opened Aug 08, 2019 by MikeyMJCO@MikeyMJCOOwner

Document entities and correct use

Created by: aydun

The background for this is the discussion on dev/membership#13 (closed) but applies more generally.

We have good docs for general usage, and for some aspects of development but we don't have anything that documents how the internal data structures relate and how to use them correctly (kinda ER but for humans!).

For example, if a membership with recurring contributions is created, what entities should result? eg membership, recurring contribution, contribution, etc. When a payment is made on that recurring contribution what should result? - contributions, payment, membership payment, line item, financial transaction, updates to membership ...

The second part of that is how each of those things is created. The line Eileen pointed out shows creating a lineitem will cause a membership payment to be created - unless it already exists, suggesting some ambiguity around whether a membership payment should have already been created. The documentation I have in mind would be something like: To create a membership with recurring contributions: create Entity1 ..., Entity2 ..., Entity3 ... and then Entity4, Entity5, Entity6 will also be created.

Our docs and API tell us for example how to create a Membership Payment, but not the bigger picture of how to correctly record a payment for membership.

A clear picture of these entity relationships and processes would provide a more robust basis for refactoring, enhancements and extensions.

Thoughts?

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: documentation/docs/dev#659