I've raised this as issue #1126 in GitLab. From the discussion, it appears that this was implemented as a 'feature' in the past but it is unclear why this was necessary. Hopefully this issue will be resolved at some point in the future but this may take some time as we need to ensure that it won't cause a regression for existing users.
As a workaround in ...
If they renew early, it should just extend their membership. (e.g. if it is an annual membership and they have 2 months left when they renew, they should have 14 months on their membership afterwards).
Just sharing that we have developed and released a CiviCRM extension which solves this problem, see https://github.com/agileware/au.com.agileware.membershiprelationshiptypeeditor
Membership Relationship Type Editor for CiviCRM - edit existing Relationship Types and re-calculate inherited memberships
We hope this is useful to people using CiviCRM.
The issue you're seeing is because you must deselect the "auto renew options" text in the third input box. You can deselect with a Ctrl-click. I just tested on my 4.4.19 demo site and could save OK with that text deselected.
I just tested this on my site, and you're right.
If you have the "Pay Later" option selected, the auto-renewal checkbox does not appear.
The checkbox should always appear, and then when the page goes through verification if 'Pay Later' is selected, and the 'auto-renew' box is selected, that should throw an error to the user.
I've created an ...
On a contribution page, it is possible to set the 'recurring' to 'offer installments: "Give the user a choice of installments (e.g. donate every month for 6 months)? If not, recurring donations will continue indefinitely." That may be one place you could look at doing a minor customisation so that rather than 'offering' the number, you specify it and hide it....
An interesting workaround is you can make a profile that includes the membership end date for bulk updating memberships, then edit the membership end date there, and save. It won't throw an error. Not sure what the unintended consequences may be.
You can probably still change it via the API - specify the new end date on the existing membership, but that may have unintended consequences.
How did you do the refund? What status is the contribution? Maybe changing the end date should be part of the refund process.
If you are using memberships with fixed dates (e.g. calendar year memberships), then there is a setting "Fixed Period Rollover Day" that will control at which point a membership for the following period can be added.
Thank you A Davidson and Peter for your ideas. After doing some more digging (did not find this post before), I came across this post, explaining how to limit the recipients of a scheduled reminder to a defined group.
I think this option will work for us.
The way you pose of updating via the UI sounds like the best plan unless you have access to a programmer who can mess around in the database for you - if you do, they can update the civicrm_membership_type table by adding the relevant relationship_type_id and relationship_direct values, and then they would probably need to run a script to update any records ...