Fix #2132 - Enabled Store Pickup Shipping Method

[amenk]

• Added config options
• Changed error in the model
• Auto-Formated system.xml (too long lines)

[choukalos]

Hey @amenk please sign the CLA so we can accept the PR, that's why this hasn't been processed in the system.

[amenk]

I signed it a couple of times before and now did again. Is this intended?

[daim2k5]

@amenk normally you only need to accept the cla once. But please do it again ;-) if not we stuck here in a loop ;-)

[amenk]

Even in this issue I already singed it!!

[amenk]

I signed it again, but the CI status is not updating.

[davidalger]

@daim2k5 and @amenk this same CLA acceptance loop is happening to me on one of my PRs too… not sure why. :)

[alankent]

I think I saw an internal email thread that CLA server had to be restarted - something had gone wrong with it.

[davidalger]

@alankent assuming the restart was completed, it didn't fix the frozen PRs. #2204 still refuses the CLA signing from me (while all my others show green correctly)

[amenk]

Tried to sign again for this one here, still does not seem to work. In one past PR it did work: #1869

[daim2k5]

From Ben:
"Update: we've resolved the issue of the crashed CLA monitor, but the PRs submitted while it was down are stuck. We're working to unstick them (Ref CICD-1981). Sorry for the friction, and thanks for understanding as we get this new process sorted out."

[davidalger]

#2132

[yariksheptykin]

Hi guys! Any updates on this issue? To me it looks like the pull request could be accepted.

[asemenenko]

Hi @yariksheptykin, apology for a long response

We looked at the pull request and we identified a list of issues preventing it to be processed. We try to avoid having too simple features available out of the box focusing on more advanced implementations that will serve needs of the much wider audience.
We would like to enable more sophisticated way to handle inventory available for in store pick up, specifically we want to support multiple pick-up locations with an ability to control their stock levels accordingly, selecting a location nearby etc. Meanwhile requested functionality can be easily added by utilizing existing Flat Rate or Free Shipping modules which Magento offers out of the box.

/regards

[amenk]

But having the basic functionality already available until then would be nice.
And free shipping is not pick up ... We have the case where we want to offer both.
Also parts of the functionality is already in the core, but just inactive / dead code. My patch just adds the missing parts.
Please reconsider.

[yariksheptykin]

Same as in @amenk mentioned, I am working on a shop which offers both: free shipping and an ability to pick up goods at the store. I was surprised to find "Store Pickup" half-ready in the magento codebase and was happy to see the patch from @amenk making this code functional. I don't see how the pull request prevents you from building upon it in order offer a "more advanced implementations that will serve needs of the much wider audience. ". To me it looks like a good starting point.

[asemenenko]

Hi @amenk and @yariksheptykin

am working on a shop which offers both

New simple module can be easily created based on existing one. While it indeed may help you having it OOTB at the same time having too many small incomplete features will create a problem for other community members. Initial version of this functionality should provide enough features to be used by independent developers/solution/technology partners that offer their extensions.
The possible list may consist of (but not limited):

• Catalog (layered navigation filters, store selector, product availability checker on product pages etc.) We also need an extension points for that to properly support 3rd party services that we can pool that data from, cache it for quicker access etc.
• In-store options requires modification of the checkout flow that includes modifications of the shopping cart as well with the extensions points. That means we need to be careful with bringing features that eventually will require to introduce major backward incompatible changes if a developer integrating with a 3rd party service will want to extend it.
• integration with a payment services should be considered during development as well. Same concern as above. When implementing it we need to make sure we allow to control different behavior for a payment acceptance flow during checkout. For example customer may be offered a "Pay In-Store" option. Also a customer can choose to pay online. On top of that such services like PayPal offer an API that allows to specify which delivery option customer have selected (see PAYMENTREQUEST_n_LOCATION_TYPE). We need to make sure we have an abstract that gives an access to such data as location (PAYMENTREQUEST_n_LOCATION_ID). Payment module should be aware of all those nuances and give an extension developers all the information required to implement their payment extension properly.
• support integration with a map service provider. Same concern as above. When implementing it we need to proved an extension points so that we can use to generate a list of stores based on say either City/Postal code/geoip information we have.

[yariksheptykin]

Thanks for taking your time explaining the issue, @asemenenko !

Just to make sure that I understand your argument correctly, let me repeat it:

1. The PR enables Store Pickup feature
2. Enabled features must meet all integration requirements.
3. Current implementation provided by PR does not meet some of the integration requirements

Therefore, reject PR.

To solve this problem a new PR has to be created that addresses all integration requirements fully (or at least the list of concerns outlined in the previous comment).
Until such a PR is created and accepted, you suggest those who need Store Pickup feature to create their own implementations.

Is this correct?