6 commits

Author	SHA1	Message	Date
Justine Tunney	5012893c1d	mv com/google/domain/registry google/registry ... This change renames directories in preparation for the great package rename. The repository is now in a broken state because the code itself hasn't been updated. However this should ensure that git correctly preserves history for each file.	2016-05-13 18:55:08 -04:00
ctingue	4112bca925	Begin writing AUTO_RENEW flag alongside reason ... Backfill [] to follow, and the Recurring billing events will eventually be replicated as OneTime via a regular job. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=119883652	2016-05-13 17:39:47 -04:00
Justine Tunney	076c8d7e27	Update copyright notice to Domain Registry Authors	2016-03-24 17:52:56 -04:00
nickfelt	7e80b5646f	Make Cancellation OneTime vs Recurring logic explicit ... This CL does a very similar cleanup to Cancellation as the diffbase does to GracePeriod - see [] It simplifes logic where we used to overload methods to accept eitherw OneTime or Recurring billing events refs, despite storing them in separate fields in the entity (since BillingEvent is not a polymorphic superclass, just a Java-only one, you can't store them as refs to BillingEvent). That overloading was ultimately only there as a convenience/hack from when we added Recurring events and didn't want to go back and change everything. It obfuscates what's really going on, requires extra casting/loss of type-safety, and relies on indirect signals (e.g. the Billing event reason being AUTO_RENEW) to guess what the right billing event type is. That latter aspect will likely no longer work in a monthly billing world, and was brittle anyways (as came up in the context of removing the AUTO_RENEW reason - see [] ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=117165174	2016-03-16 21:20:25 -04:00
nickfelt	9786e6732f	Make GracePeriod OneTime vs Recurring logic explicit ... This CL cleans up some old crufy logic in GracePeriod that overloaded methods to accept either OneTime or Recurring billing events refs, despite storing them in separate fields in the entity (since BillingEvent is not a polymorphic superclass, just a Java-only one, you can't store them as refs to BillingEvent). That overloading was ultimately only there as a convenience/hack from when we added Recurring events and didn't want to go back and change everything. It obfuscates what's really going on, requires extra casting/loss of type-safety, and relies on indirect signals (e.g. the grace period type being AUTO_RENEW) to guess what the right billing event type is. That latter aspect will likely no longer work in a monthly billing world, and was brittle in any case. A coming CL will rip the same logic out of Cancellation. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=117164286	2016-03-16 21:20:25 -04:00
Justine Tunney	0ef0c933d2	Import code from internal repository to git	2016-03-01 17:59:16 -05:00