draft_approve 0.1.0

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA256:
+  metadata.gz: 778e1169104c109857ae10ab5be887080d7cd6128dbffe51e8a339fd49fff197
+  data.tar.gz: c744acb2e0f8c2262407864860edb42c5153e498d651071f63a4fb4f0fca423d
+SHA512:
+  metadata.gz: da0f2ee7cca8abb87de7448178fa86fbe5e083b832c89b3d604d557602c18026c062c12bf80a5148d24507e41eec728ed4fd92780b02ae95c8724cb9c5dd2d2e
+  data.tar.gz: d72607ca1a9dd39a82fce60863b1e2a368afbc9f5d6c3ae4ce315d51de5625bc01318a5f11d446f8af26cd456991d6236b9cbd2b9ed3417e304babfc78415acb

data/.gitignore

@@ -0,0 +1,11 @@
+/.bundle/
+/.yardoc
+/_yardoc/
+/coverage/
+/doc/
+/pkg/
+/spec/reports/
+/tmp/
+
+# rspec failure tracking
+.rspec_status

data/.rspec

@@ -0,0 +1,3 @@
+--format documentation
+--color
+--require spec_helper

data/.travis.yml

@@ -0,0 +1,7 @@
+---
+sudo: false
+language: ruby
+cache: bundler
+rvm:
+  - 2.5.3
+before_install: gem install bundler -v 1.17.0

data/.yardopts

@@ -0,0 +1,6 @@
+--exclude lib/generators/draft_approve/migration/templates/
+--readme README.md
+lib/**/*.rb
+-
+CODE_OF_CONDUCT.md
+LICENSE.md

data/Appraisals

@@ -0,0 +1,3 @@
+appraise "rails-5-2-0" do
+  gem "activerecord", "~> 5.2.0"
+end

data/CODE_OF_CONDUCT.md

@@ -0,0 +1,74 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at TODO: Write your email address. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

data/Gemfile

@@ -0,0 +1,6 @@
+source "https://rubygems.org"
+
+git_source(:github) {|repo_name| "https://github.com/#{repo_name}" }
+
+# Specify your gem's dependencies in draft_approve.gemspec
+gemspec

data/Gemfile.lock

@@ -0,0 +1,91 @@
+PATH
+  remote: .
+  specs:
+    draft_approve (0.1.0)
+      activerecord (~> 5.2)
+
+GEM
+  remote: https://rubygems.org/
+  specs:
+    activemodel (5.2.2)
+      activesupport (= 5.2.2)
+    activerecord (5.2.2)
+      activemodel (= 5.2.2)
+      activesupport (= 5.2.2)
+      arel (>= 9.0)
+    activesupport (5.2.2)
+      concurrent-ruby (~> 1.0, >= 1.0.2)
+      i18n (>= 0.7, < 2)
+      minitest (~> 5.1)
+      tzinfo (~> 1.1)
+    appraisal (2.2.0)
+      bundler
+      rake
+      thor (>= 0.14.0)
+    arel (9.0.0)
+    codecov (0.1.14)
+      json
+      simplecov
+      url
+    coderay (1.1.2)
+    concurrent-ruby (1.1.4)
+    database_cleaner (1.7.0)
+    diff-lcs (1.3)
+    docile (1.3.1)
+    factory_bot (4.11.1)
+      activesupport (>= 3.0.0)
+    i18n (1.5.3)
+      concurrent-ruby (~> 1.0)
+    json (2.1.0)
+    method_source (0.9.2)
+    minitest (5.11.3)
+    pg (1.1.4)
+    pry (0.12.2)
+      coderay (~> 1.1.0)
+      method_source (~> 0.9.0)
+    rake (10.5.0)
+    rspec (3.8.0)
+      rspec-core (~> 3.8.0)
+      rspec-expectations (~> 3.8.0)
+      rspec-mocks (~> 3.8.0)
+    rspec-core (3.8.0)
+      rspec-support (~> 3.8.0)
+    rspec-expectations (3.8.2)
+      diff-lcs (>= 1.2.0, < 2.0)
+      rspec-support (~> 3.8.0)
+    rspec-mocks (3.8.0)
+      diff-lcs (>= 1.2.0, < 2.0)
+      rspec-support (~> 3.8.0)
+    rspec-support (3.8.0)
+    simplecov (0.16.1)
+      docile (~> 1.1)
+      json (>= 1.8, < 3)
+      simplecov-html (~> 0.10.0)
+    simplecov-html (0.10.2)
+    sqlite3 (1.3.13)
+    thor (0.20.3)
+    thread_safe (0.3.6)
+    tzinfo (1.2.5)
+      thread_safe (~> 0.1)
+    url (0.3.2)
+    yard (0.9.18)
+
+PLATFORMS
+  ruby
+
+DEPENDENCIES
+  appraisal (~> 2.2)
+  bundler (~> 1.17)
+  codecov (~> 0.1)
+  database_cleaner (~> 1.7)
+  draft_approve!
+  factory_bot (~> 4.11)
+  pg (>= 0.18, < 2.0)
+  pry (~> 0.12)
+  rake (~> 10.0)
+  rspec (~> 3.0)
+  sqlite3 (~> 1.3)
+  yard (~> 0.9.18)
+
+BUNDLED WITH
+   1.17.0

data/LICENSE.md

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2019, 38 Degrees Ltd
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

data/README.md

@@ -0,0 +1,329 @@
+# DraftApprove
+
+DraftApprove is a Ruby gem which lets you save draft changes of your ActiveRecord models to your database. It allows grouping of related changes into a 'Draft Transaction' which must be approved or rejected as a whole, rather than allowing individual draft changes to be applied independently.
+
+There are a number of other similar Ruby gems available for drafting changes to ActiveRecord models. Depending upon your projects needs, another gem may be more suitable. See the [Alternative Drafting Gems](#alternative-drafting-gems) section for full details.
+
+The specific features / functionality offered by DraftApprove are:
+
+* No changes are needed to your existing database tables
+* No updates are required to your existing ActiveRecord queries or raw SQL queries
+* It is possible to save drafts of new records, save draft changes to existing records, and save draft deletions of records
+* Multiple related draft changes (new records, updates, deletions) may be grouped together in a 'Draft Transaction' which must then be approved or rejected as a whole
+  * This includes being able to save a draft of a model which references an _unsaved_ model - as long as that unsaved model already has a draft
+* Each model may only have one pending draft at a time
+
+## Installation
+
+Add this line to your application's Gemfile:
+
+```ruby
+gem 'draft_approve'
+```
+
+And then execute:
+
+    $ bundle
+
+Or install it yourself as:
+
+    $ gem install draft_approve
+
+Once installed, you must generate the migration to create the required draft tables in your database, and run the migration:
+
+```
+$ rails generate draft_approve:migration
+$ rails db:migrate
+```
+
+## Usage
+
+### Make your Models draftable
+
+Add `acts_as_draftable` to all models you'd like to be draftable. For example:
+
+```ruby
+class Person < ActiveRecord::Base
+  has_many :contact_addresses
+  acts_as_draftable
+end
+
+class ContactAddress < ActiveRecord::Base
+  belongs_to :person
+  acts_as_draftable
+end
+```
+
+### Create a draft for a single object
+
+Call `draft_save!` to save a draft of a new model, or save draft changes to an existing model.
+
+Call `draft_destroy!` to draft the deletion of the model.
+
+There are also convenience methods `draft_create!` and `draft_update!`.
+
+For example:
+
+```ruby
+### CREATE EXAMPLES
+
+# Save draft of a new model
+person = Person.new(name: 'new person')
+draft = person.draft_save!
+
+# Short-hand to save draft of a new model
+draft = Person.draft_create!(name: 'new person')
+
+### UPDATE EXAMPLES
+
+# Save draft changes to an existing person
+person = Person.find(1)
+person.name = 'update existing person'
+draft = person.draft_save!
+
+# Short-hand to save draft changes to an existing person
+draft = person.draft_update!(name: 'update existing person')
+
+### DELETE EXAMPLES
+
+# Draft delete an existing person
+person = Person.find(2)
+draft = person.draft_destroy!
+```
+
+### Create multiple related drafts
+
+If you want to ensure multiple related changes are all approved, or all rejected, as a single block, use a Draft Transaction. You do this by calling the `draft_transaction` method on any draftable model class, and passing it a block where all your drafts are saved. You use the same `draft_save!` and `draft_destroy!` methods within the Draft Transaction.
+
+For example:
+
+```ruby
+draft_transaction = Person.draft_transaction do
+  # Want reference to person object, so don't use shorthand draft_create! method
+  person = Person.new(name: 'new person name')
+  person.draft_save!
+
+  existing_contact_address = ContactAddress.find(1)
+  existing_contact_address.draft_update!(person: person)
+
+  ContactAddress.find(2).draft_destroy!
+end
+```
+
+This would create 3 drafts (one to create a new person, one to update an existing contact address, and one to delete a different contact address). These must all be applied together, or all be rejected.
+
+### Approve drafts
+
+Regardless of how a draft was created, a Draft Transaction is always created, and the Draft Transaction is what needs to be approved. This will apply the changes in all drafts within the Draft Transaction (which may only be one draft).
+
+For example:
+
+```ruby
+# If you have reference to a Draft object
+draft.draft_transaction.approve_changes!(reviewed_by: 'my_username', review_reason: 'Looks Good!')
+
+# If you have reference to a DraftTransaction object
+draft_transaction.approve_changes!(reviewed_by: 'my_username', review_reason: 'Looks Good!')
+```
+
+### Reject drafts
+
+This will reject all changes in all drafts within the Draft Transaction (which may only be one draft).
+
+For example:
+
+```ruby
+# If you have reference to a Draft object
+draft.draft_transaction.reject_changes!(reviewed_by: 'my_username', review_reason: 'Nope!')
+
+# If you have reference to a DraftTransaction object
+draft_transaction.reject_changes!(reviewed_by: 'my_username', review_reason: 'Nope!')
+```
+
+### Find drafts pending approval
+
+As discussed, all drafts are created inside a Draft Transaction, and it is these which must be approved or rejected.
+
+You can find all Draft Transactions with a particular status using the following methods:
+
+```ruby
+pending_draft_transactions = DraftTransaction.pending_approval
+
+approved_draft_transactions = DraftTransaction.approved
+
+rejected_draft_transactions = DraftTransaction.rejected
+```
+
+### Errors
+
+If an error occurs while approving a transaction, the error will cause the transaction to fail, so none of the draft changes will be applied. The Draft Transaction will have its `status` set to `approval_error`, and its `error` column will contain more information (the error and the backtrace).
+
+All Draft Transactions with an error can be found using the following:
+
+```ruby
+errored_draft_transactions = DraftTransaction.approval_error
+```
+
+### Advanced usage
+
+#### Who created a draft?
+
+When creating a Draft Transaction, you may pass in a `created_by` string. This could be a username or the name of an automated process, and will be stored in the `DraftTransaction.created_by` column in the database. This option is only available when saving drafts within an explicit Draft Transaction.
+
+For example:
+
+```ruby
+draft_transaction = Person.draft_transaction(created_by: 'UserA') do
+  Person.new(name: 'new person name').draft_save!
+end
+```
+
+#### Extra metadata for drafts
+
+When creating a Draft Transaction, you may pass in an `extra_data` hash. This can contain anything, and will be stored in the `DraftTransaction.extra_data` column in the database. This option is only available when saving drafts within an explicit Draft Transaction.
+
+Possible use-cases for the extra data hash are storing which users or roles are allowed to approve these drafts, storing additional data about why or how the drafts were created, etc. The DraftApprove gem does not implement these features for you (eg. limiting who can approve drafts), but simply gives you a way to store generic metadata about a Draft Transaction should you wish to build such features within your application logic.
+
+For example:
+
+```ruby
+extra_data = {
+  'can_be_approved_by' => ['SuperAdminRole', 'UserB'],
+  'data_source_url' => 'https://en.wikipedia.org/wiki/RubyGems',
+  'data_scraped_at' => '2019-02-08 12:00:00'
+}
+
+draft_transaction = Person.draft_transaction(extra_data: extra_data) do
+  Person.new(name: 'new person name').draft_save!
+end
+```
+
+#### Skipping validations when saving drafts
+
+By default, models will have their ActiveRecords validations checked before a draft is saved. This prevents invalid drafts from being persisted, which would just fail validation when the Draft Transaction is approved anyway.
+
+_Side note - when saving a draft, only ActiveRecord validations are checked. Since the draft data is not written to your application table, database-only validations cannot be checked!_
+
+If you would like to skip checking ActiveRecord validations when saving a draft, you may pass the `validate: false` option to `draft_save`, for example:
+
+```
+person = Person.new
+person.draft_save!(validate: false)
+```
+
+Validations will still run when the draft is approved, so this option is not especially useful unless combined with a custom method for creating or updating the record (see below).
+
+#### Custom methods for creating, updating and deleting data
+
+When a Draft Transaction is approved, all drafts within the transaction are applied, meaning the changes within the draft are made live on the database. This is acheived by calling suitable ActiveRecord methods. The default methods used by the DraftApprove gem are:
+
+* `create!` for new models saved with `draft_save!`
+* `update!` for existing models which have been modified and saved with `draft_save!`
+* `destroy!` for models which have had `draft_destroy!` called on them
+
+Note that `create!` is a _class_ level ActiveRecord method, while `update!` and `destroy!` are _instance_ level ActiveRecord methods.
+
+When saving drafts, you may override the method used to save the changes by passing an options hash to the `draft_save!` or `draft_destroy!` methods. You are not able to do this with the convenience `draft_create!` or `draft_update!` methods.
+
+For example:
+
+```ruby
+draft_transaction = Person.draft_transaction do
+  # When approved, find or create Person A
+  person = Person.new(name: 'Person A')
+  person.draft_save!(create_method: :find_or_create_by!)
+
+  # When approved, update the record ignoring validations
+  existing_person = Person.find(1)
+  existing_person.birth_date = '1800-01-01'
+  existing_person.draft_save!(update_method: :update_columns)
+
+  # When approved, delete the record directly in the database without any ActiveRecord callbacks
+  Person.find(2).draft_destroy!(delete_method: :delete)
+end
+```
+
+**CAUTION**
+* No validation is done to check you are using sensible alternative methods, so use at your own risk!
+* **It is strongly recommended to use methods which will raise an error if they fail**, otherwise one draft in a Draft Transaction may 'silently' fail, causing subsequent drafts to be applied, and the Draft Transaction as a whole may appear to have been successfully approved & applied
+* Methods used as the `create_method` **must** be _class_ methods for the model you are drafting, which accept a hash of attribute names to attribute values (eg. `Person.create!`, `Person.find_or_create_by!`, etc)
+* Methods used as the `update_method` **must** be _instance_ methods for the model you are drafting, which accept a hash of attribute names to attribute values (eg. `person.update!`, `person.update_attributes!`, etc)
+* Methods used as the `delete_method` **must** be _instance_ methods for the model you are drafting, which requires no arguments (eg. `person.destroy!`, `person.delete`, etc)
+
+### More examples
+
+Further examples can be seen in the [integration tests](spec/integration).
+
+## Frequently Asked Questions
+
+### Why am I getting `ActiveRecord::RecordInvalid` errors when I save a draft?
+
+If you wish to purposefully save drafts which do not pass validations, see the [Skipping validations when saving drafts](#skipping-validations-when-saving-drafts) section.
+
+If you are unexpectedly getting `ActiveRecord::RecordInvalid` errors, a _possible_ reason is explicit validations on foreign key columns. For example, the following would fail:
+
+```ruby
+class Person < ActiveRecord::Base
+  has_many :contact_addresses
+  acts_as_draftable
+end
+
+class ContactAddress < ActiveRecord::Base
+  belongs_to :person
+  validates :person_id, presence: true  # This validation is unnecessary and can cause errors
+  acts_as_draftable
+end
+
+draft_transaction = Person.draft_transaction do
+  # Create a new person, and save it as a draft (note, this means p.id is nil!)
+  p = Person.new(name: 'person name')
+  p.save_draft!
+
+  c = ContactAddress.new(person: p)
+  c.save_draft!  # raises ActiveRecord::RecordInvalid because contact_address.person_id is nil
+end
+```
+
+This can be fixed by removing the explicit `presence: true` validation of foreign key columns. Such validations should not be necessary anyway, because by default `belongs_to` relationships validate the associated object is not `nil`.
+
+_Side note: the `belongs_to` validations do not cause such errors when saving a draft because they check the associated object (eg. `person`) is not `nil` - rather than validating that the component attributes / columns of the association (eg. `person_id`) are not `nil`. In the example above, the `belongs_to` validation would check `contact_address.person` is not `nil`, which it is not - the `Person` object referred to has not been persisted, but it is not `nil`, so the validation passes._
+
+## Alternative Drafting Gems
+
+* [Drafting](https://github.com/ledermann/drafting)
+* [DraftPunk](https://github.com/stevehodges/draftpunk)
+* [Draftsman](https://github.com/jmfederico/draftsman)
+
+**DraftPunk** and **Draftsman** both require changes to your existing database tables. In itself, this is not a problem, however this also _potentially_ requires changes to your ActiveRecord Queries and any raw SQL you may be executing in order to ensure draft models or draft changes are not accidentally returned by queries or shown to end users.
+
+This problem can be avoided using default scopes on your models. This may be a suitable solution for new projects, or projects which don't utilise much or any raw SQL queries.
+
+See the [DraftPunk documentation](https://github.com/stevehodges/draftpunk#what-about-the-rest-of-the-application-people-are-seeing-draft-businesses) and [Draftsman documentation](https://github.com/jmfederico/draftsman#drafted-item-scopes) on using scopes.
+
+**Drafting** does not require any modifications to existing tables, and therefore has no risk of existing queries accidentally returning draft data. However, [it only allows saving drafts on records which are not persisted yet](https://github.com/ledermann/drafting#hints). This may be suitable for projects where it is not necessary to create and approve draft updates to objects.
+
+All the above gem also have other specific features / advantages unique to them, so before selecting the most suitable gem for your needs, it is recommended you read their documentation and trial them to find which is most suited to your project requirements.
+
+## License
+
+[MIT License](LICENSE.md)
+
+Copyright (c) 2019, 38 Degrees Ltd
+
+## Development
+
+After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake spec` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.
+
+To install this gem onto your local machine, run `bundle exec rake install`. Alternatively you may run `gem build draft_approve.gemspec` to generate the `.gem` file, then run `gem install ./draft_approve-0.1.0.gem` (replace `0.1.0` with the correct gem version).
+
+To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).
+
+To generate the YARD documentation locally, run `yard doc`, which will install the documentation into the `doc/` folder.
+
+## Contributing
+
+Bug reports and pull requests are welcome on GitHub at https://github.com/38dgs/draft_approve. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](http://contributor-covenant.org) code of conduct.
+
+## Code of Conduct
+
+Everyone interacting in the DraftApprove project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the [code of conduct](https://github.com/38dgs/draft_approve/blob/master/CODE_OF_CONDUCT.md).