[SOLVED] [#9091] Programmatically invoice a subscriber

Regarding that particular case, our goal was to limit the ability for a user to subscribe to plan 27 until we supplied the link for them to add it to their basket.

That's done by using the below parameters under the Workflows tab.

Propose spontaneously plan at registration: No: hide this plan from registration and from access proposals, unless specifically included in URL
Propose spontaneously plan for upgrades: No: hide this plan from upgrades and from access proposals, unless specifically included in URL

This ensures the plan is only available if directly linked to.

We don't want them to be able to choose to subscribe to the plan on-demand because it represents a certification they must meet requirements to achieve. Is there a better way to control the exact moment a user is offered plan 27 for subscription and still be able to apply the promotion to adjust their fee for GDP?

The above won't prevent access if they know the URL. The only other option is either a condition or access check on the plan. For example you could have a checkbox field only available to moderators that you check against so if you want them to have access to it you simply check that checkbox field for them. Another option is a usergroup that you could give them then just set the Access parameters of the plan as needed.

Concerning promotions in general, I've also tested with the promotion named "Test ECMS Fee" and tried various settings from different promotion types to different plans, plans that are available on the frontend, to just a blanket percent promotion on any plan. The promotion was never applied in the basket. The only condition on that promotion is a specific user ID of a test user I was testing with.

That promotion does not work due to having no usergroup or view access level configured under the Access tab. Set both to Public and it should work fine.

That's done by using the below parameters under the Workflows tab.

Propose spontaneously plan at registration: No: hide this plan from registration and from access proposals, unless specifically included in URL
Propose spontaneously plan for upgrades: No: hide this plan from upgrades and from access proposals, unless specifically included in URL

This ensures the plan is only available if directly linked to.

Yes, I've since set that workflow parameter to "Propose spontaneously plan for upgrades: No: hide this plan from upgrades and from access proposals, unless specifically included in URL". That sufficiently hid the plan from the view of frontend users to select it themselves.

The above won't prevent access if they know the URL. The only other option is either a condition or access check on the plan. For example you could have a checkbox field only available to moderators that you check against so if you want them to have access to it you simply check that checkbox field for them. Another option is a usergroup that you could give them then just set the Access parameters of the plan as needed.

We have a field that is set to a value of 1 when the user is allowed to subscribe to plan 27. And, I've set a condition in the plan that the field value must be greater than zero (because the field value increments each time the user cancels the invoice).

However, based on the language in the plan config that condition only applies to upgrades. And, as my test user, even if I don't meet the plan condition I'm still able to visit the addplantobasket URL directly and have an invoice created. So, even with the condition it doesn't seem to prevent access if they know the URL. Other than the condition config on the Workflow tab for subscription upgrades, I'm not finding the ability to set any other condition in the plan for access.

The condition shouldn't be ignored for direct URL access. My guess is your condition is validating. What field type are you using? That should be an integer field.

It's currently a text field. Perhaps it's being evaluated as a string in that case. I'll try changing it to an integer field.

I changed the field being evaluated in the plan condition from a text field to an integer field. My test user has a field value of 0 so the condition (field > 0) should not validate. However, I can login as the test user and still access the addplanstobasket URL.

Does access, or lack there of, to the field matter? It's published but read-only. And, all frontend displays for the field are disabled - profile, registration, edit, and searchable.

Does access, or lack there of, to the field matter? It's published but read-only. And, all frontend displays for the field are disabled - profile, registration, edit, and searchable.

Try setting the field to be not read only and set it to display on profile next move it to a tab that's in a not shown on profile position that also has public access. This ensures the field is fully accessible during all operations. Once done see if that resolves your issue. Very strange that it's not working as is though.