Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • G gitlabhq1
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 21
    • Issues 21
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 12
    • Merge requests 12
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • gpt
  • large_projects
  • gitlabhq1
  • Merge requests
  • !1208

Merged
Created Aug 09, 2012 by Administrator@rootOwner

Consolidate functionality shared between Issue and MergeRequest

  • Overview 3
  • Commits 3
  • Changes 5

Created by: rspeicher

Summary

Any associations, validations, delegates, scopes and methods that were exactly the same in both Issue and MergeRequest models have been moved to a new IssueCommonality module (role) that gets included by each class.

There was actually quite a bit of duplication, because MergeRequests are basically just specialized Issues.

"IssueCommonality"?

I had a bit of a hard time coming up with a name for the module, and I'm still not entirely satisfied with it, but I think it does a good enough job of describing what it does without being too verbose.

commonality |ˌkämənˈalitē| noun ( pl. commonalities ) 1 the state of sharing features or attributes: a commonality of interest ensures cooperation.

Specs?

First, there's probably now a bit of duplication in the model specs for these two classes, but I haven't done anything with that yet.

Second, I was unable to get a full development environment running that actually passed all the tests before I made these changes. I did run the two model specs, and those passed, but a quick "Developer Bootstrap" guide on the wiki or something would be much appreciated, and probably get the project some more contributors.

Assignee
Assign to
Reviewer
Request review from
Time tracking
Source branch: github/fork/rspeicher/issue_commonality