MORG Cloning for next year (INTERPODIA ADMIN ONLY)


Pro tip: 

If you have a setup sheet from the previous season (eg: OE extended season), you should copy it, and remove all IDs from the new version before cloning. That way you can remember exactly what to check/update once you've cloned the morg, and add the new season IDs to the setup sheet for fast updates later in the season. 


If the morg you're cloning from has any memberships that have node types, you should turn off ‘automatic node type checking’ on the old morg once the new morg is live.  Set a calendar reminder to go into the morg and change the Issued membership email on the go live date of the new season (this date could be different for HorseReg clients with extended memberships).


Choose "clone MORG for next year"


What WILL clone;

  • Membership Organization

Don't forget to remove the slug from the listing name + URL

The system DOES NOT update: 

    • Age as of
    • Reg open/close dates
  • GroupGroupGrants (PSO membership granting NSO membership)

System clone but DOES NOT update the granted group ID. You usually need to:

    • create the new granted groups under the current year morg (if extended), those DO NOT clone
    • or clone the parent morg (when NSO is granted)

Then, update the granted group IDs on the cloned groupgroupgrants

  • GroupGroups
  • Groups

The system does update regular year (eg: 2021 to 2022) but will not update season or extended name (eg: 2020-2021 would become 2020-2022), so to update where applicable.

+ System DOES NOT update: 

    • earliest effective date
    • availability date
  • Nodes

The system does update regular year (eg: 2021 to 2022) but will not update season or extended name (eg: 2020-2021 would become 2020-2022), so to update where applicable.

  • Nodes types

THEY DO NOT CLONE PER SE, but the existing node types are being added to the cloned nodes, which is what you need most of the time. 

The only case you might need to create a new node type, and then update your cloned node, is when the node type is based on a DateTime requirement with a specific date range as a rule, or a Backcheck with a specific date range as a rule

Any node type linked to an attribute value, DateTime requirement with a rule that is X year prior/after, backcheck with a rule that is X year prior/after SHOULD STAY THE SAME year after year. 

  • Prices & Discounts

Update the name if applicable, and remove the slug

  • Surveys & Questions

Update year if applicable, and remove the slug. Double-check your survey displays

  • Waivers

Don't forget to update the year in the name, and remove the cloning slug (the cloning slug shows in BOTH the waiver name AND the language mutation name)

  • Filters & Filter sets

Don't forget to update the name of the filter sets + the qty filter are being cloned BUT NOT updated with the new groups or morgs, you must update the qty filters with the new morg/group ids. 

  • (Fundraising) Campaigns

New campaigns are being created, if the campaign includes the year/season in the name, don't forget to update it.

For horse clients:

We use one campaign per calendar year, it doesn't matter which membership I'm currently buying, I would give to the campaign of the year based on the date I'm making the purchase. 
eg: If I'm buying a 2022 membership in October 2021, what should display should be the 2021 campaign option(s)

To ensure that, when cloning the system will: 

- Clone campaign from years n-1 ad n-2: you need to delete the n-2 clones and rename the n-1 clone with the n year (year of the new process you're building)

- Those new n year campaign needs to have open at / close at date from: n/01/01 to n/12/31

- Campaign display: on morg n you should have a display for campaign(s) n and n-1


Eg with OE 2022 process, I'm displaying both the 2021 and the 2022 campaign, because of the open/close date, if I'm buying a membership in 2021 I'll be able to donate to the 2021 campaign, and if I'm buying in 2022 I'll be able to donate to the 2022 campaign. 

  • Number Generator & Generator Application

If indicated in the Generator name, you should update the generator application to keep the existing one and delete the one that has been cloned. 

  • Templates (member cards)

Templates are being cloned as is, you must update the group ids in the variable if there is any. 


What WILL NOT clone;

  • Family membership setup (only the groups are being cloned)

See HOW TO SETUP FAMILY MEMBERSHIP to finish the missing setup. 

  • Autogeneration Settings (and all the other member card setups that are not templates)

See HOW TO SETUP MEMBERSHIP CARD ARTICLE to finish the missing setup. Steps 2 to 4 are missing. 

  • Plugin Applications (API calls i.e UCI ID, etc)
  • Process_App configuration (membership processing queues)
  • Stores

For the store, you can display them on a placeholder event, and clone the event with the option 'clone stores' and then display the new stores (removing the slugs) in your new membership process. 

Note: when cloning (via event cloning) a store with surveys attached to a product or requires logic between 2 products, those setups DO NOT clone