vaidashi/Open Source Review (Spree) - Danny & Ash

## Open Source Review (Spree) - Danny & Ash
For our open source project, we chose the Spree library https://github.com/spree/spree/blob/master/.github/CONTRIBUTING.md which is an open source ecommerce solution for Ruby on Rails. The issue chosen was https://github.com/spree/spree/issues/7734 . The issue consisted of a bug where users could promotions as they checked out an order, but the order total not limiting the discount amount to $0.

To get started, we followed the procedures to clone down the repo. Immediately, we encountered an error on our ruby version and had to update from 2.4.1 to 2.4.2 . Then, our next issue preventing us from setting up the repo successfully was installing the MySQL database; specifically, MySQL 2.

Once we successfully cloned down the environment we found they had created several sub-environments in the Spree application. One for testing (Core) and one for spinning up your local development environment (Sandbox). Additionally, another new feature we saw was a directory structure breaking down into front-end, back-end, and API directories. This structure was something we had not been taught, or had seen while at Turing.

It was interesting and challenging trying to navigate the layers of functionality, and where they resided in the application’s codebase. Spree also has an interesting database organization as there is heavy use of database normalization. An example being promotions having their actions abstracted out. Their application on line items and categories was also elaborate and somewhat confusing to decipher. To give an understanding, to reference a promotion you need to navigate the promotion table, promotion rule table, promotion rule users table, promotion rule tax-ons, promotion actions, and finally promotion action line items. As new developers, there were many issues which seemed beyond our scope to fix in the time allotted, but this issue seemed the most approachable to dive into, despite its structure.

In order to resolve our chosen issue, after tracking through files to find the appropriate place to list our constraint / conditional, we decided to proceed with writing a test. Writing that test was also required in order for our contribution to be accepted assuming we had fixed the issue. Our solution was to include our conditional in the Promotion Handler Module, in the Activate method specifically. This conditional would test that a promotion could not be applied and it would be deactivated if it caused the overall cart order total to be a negative dollar amount.

We were unable to have our test pass and thus are not certain if our addition would be a workable solution. Also, a challenging part was that we could not log in as an admin user and see promotions to add on our checkout in a live environment as a means of testing. We couldn’t find the documentation to list a default admin user account credentials for testing purposes.

Despite our best efforts and given the time allotted, we were not able to find a solution; however, it was a great experience to see what it would be like to contribute in an open source project and to dive into an application and attempt to analyze the different functional pieces of a working and production-deployed app that is utilized by many clients.
	For our open source project, we chose the Spree library https://github.com/spree/spree/blob/master/.github/CONTRIBUTING.md which is an open source ecommerce solution for Ruby on Rails. The issue chosen was https://github.com/spree/spree/issues/7734 . The issue consisted of a bug where users could promotions as they checked out an order, but the order total not limiting the discount amount to $0.

	To get started, we followed the procedures to clone down the repo. Immediately, we encountered an error on our ruby version and had to update from 2.4.1 to 2.4.2 . Then, our next issue preventing us from setting up the repo successfully was installing the MySQL database; specifically, MySQL 2.

	Once we successfully cloned down the environment we found they had created several sub-environments in the Spree application. One for testing (Core) and one for spinning up your local development environment (Sandbox). Additionally, another new feature we saw was a directory structure breaking down into front-end, back-end, and API directories. This structure was something we had not been taught, or had seen while at Turing.

	It was interesting and challenging trying to navigate the layers of functionality, and where they resided in the application’s codebase. Spree also has an interesting database organization as there is heavy use of database normalization. An example being promotions having their actions abstracted out. Their application on line items and categories was also elaborate and somewhat confusing to decipher. To give an understanding, to reference a promotion you need to navigate the promotion table, promotion rule table, promotion rule users table, promotion rule tax-ons, promotion actions, and finally promotion action line items. As new developers, there were many issues which seemed beyond our scope to fix in the time allotted, but this issue seemed the most approachable to dive into, despite its structure.

	In order to resolve our chosen issue, after tracking through files to find the appropriate place to list our constraint / conditional, we decided to proceed with writing a test. Writing that test was also required in order for our contribution to be accepted assuming we had fixed the issue. Our solution was to include our conditional in the Promotion Handler Module, in the Activate method specifically. This conditional would test that a promotion could not be applied and it would be deactivated if it caused the overall cart order total to be a negative dollar amount.

	We were unable to have our test pass and thus are not certain if our addition would be a workable solution. Also, a challenging part was that we could not log in as an admin user and see promotions to add on our checkout in a live environment as a means of testing. We couldn’t find the documentation to list a default admin user account credentials for testing purposes.

	Despite our best efforts and given the time allotted, we were not able to find a solution; however, it was a great experience to see what it would be like to contribute in an open source project and to dive into an application and attempt to analyze the different functional pieces of a working and production-deployed app that is utilized by many clients.