Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved Stock Item configuration #2297

Closed
wants to merge 11 commits into from
Closed

Conversation

aleron75
Copy link
Contributor

@aleron75 aleron75 commented Jun 4, 2019

Description

This PR is intended as a rework of PR #1553 which addresses issue #1486.

This is still a work in progress solution, labeled as WIP and used to discuss implementation.

In the initial PR I've:

Contribution checklist (*)

  • Pull request has a meaningful description of its purpose
  • All commits are accompanied by meaningful commit messages
  • All new or changed code is covered with unit/integration tests (if applicable)
  • All automated tests passed successfully (all builds on Travis CI are green)

This change is intended to make the StockItem configuration pure immutable, representing the indexed and aggregated data.
Refer to https://github.com/magento-engcom/msi/wiki/Stock-and-Source-Configuration-design#programming-interface-query-api
This update sets the `nullable` attribute of `value` column to `true` so that it can be possible to nullify values once they are saved.
This commit adds the declaration for the `GetBackorderStatusConfigurationValue` and `SetBackorderStatusConfigurationValue` service.
The `SetBackorderStatusConfigurationValue` has been implemented (still to refine), next step is adding integration tests.
@aleron75
Copy link
Contributor Author

aleron75 commented Jun 4, 2019

In order to reduce the number of routes in webapi.xml, we've chosen to implement an additional method (which I called execute()) in the service layer and bind this method to the routes.

Depending on passed parameters, the execute() method proxies the call to the proper one.
In the execute() method, the value is a string because it should be possible to have an optional parameter; declaring it as int didn't work.

There are some TODO comments which indicate things that need to be discussed together.

* @param string|null $sourceCode
* @return int|null
*/
public function execute(string $sku = null, string $sourceCode = null): ?int;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

execute method definitely creates confusion, given that other methods have clear names and execute is usually used to trigger Functor

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need a method to map to a route which is not one of the above Command Facades because to reduce routes we decided to use one method which proxies to Command Facades.
Since the class name already expresses the intention, what would be a better name for you?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we look for ways to extract this part related to Web API?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, an InventoryConfigurationWebapi module would be the perfect candidate I guess.

But that doesn't solve the execute naming issue, given we still want to go with one route per option, differentiating based on parameters in the body.

What would be an appropriate naming for the function called by the get and set web API?

* All APIs to specify Backorder Config Value on the level of SourceItem/Source/Globally
* @api
*/
interface SetBackorderStatusConfigurationValueInterface
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comments as for Get interface apply

<route url="/V1/inventory/configuration/backorders" method="GET">
<service class="Magento\InventoryConfigurationApi\Api\GetBackorderStatusConfigurationValueInterface" method="execute"/>
<resources>
<resource ref="Magento_Backend::admin"/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we look for more specific access level?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably yes, something like Magento_InventoryApi::configuration?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think it should be sufficient at this point.

*/
public function forGlobal(int $backorderStatus): void
{
// TODO should validate allowed values?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Imo validation would save a lot of time in the future

return;
}

if (!is_numeric($backorderStatus)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is_numeric might allow values we don't want here (floats, some hex or binary values, larger numbers with powers,
etc)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

got it; maybe after introducing validation I can be more specific here

@@ -64,11 +66,6 @@ interface StockItemConfigurationInterface extends \Magento\Framework\Api\Extensi
*/
public function isQtyDecimal(): bool;

/**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing methods from the interface would break BC and therefore postpone this feature to the later releases. Should we look for ways to preserve methods?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed those methods to follow the directive here that asks for immutability. Let me know which way you prefer to follow.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

General approach for immutability is still in works, so I'm not sure if we should remove methods right away. Still, it's possible that once this PR is ready we would be working on a release which would allow some changes to the interfaces.

In short, I'd keep it at this point. We can always remove it down the road if it looks like a good idea then

@okorshenko okorshenko added this to Work in Progress in Pull Request Progress Jul 10, 2019
@m2-community-project m2-community-project bot moved this from Work in Progress to Review in Progress in Pull Request Progress Jul 10, 2019
@ishakhsuvarov ishakhsuvarov moved this from Review in Progress to Work in Progress in Pull Request Progress Jul 10, 2019
@ishakhsuvarov ishakhsuvarov changed the title MSI 1486 rework Improved Stock Item configuration Jul 10, 2019
@m2-community-project m2-community-project bot moved this from Work in Progress to Review in Progress in Pull Request Progress Jul 10, 2019
@ishakhsuvarov ishakhsuvarov moved this from Review in Progress to Work in Progress in Pull Request Progress Sep 4, 2019
@ishakhsuvarov ishakhsuvarov changed the base branch from 2.3-develop to 1.1-develop September 16, 2019 18:13
@m2-community-project m2-community-project bot moved this from Work in Progress to Review in Progress in Pull Request Progress Sep 16, 2019
@ishakhsuvarov ishakhsuvarov changed the base branch from 1.1-develop to 2.3-develop September 16, 2019 21:15
@ishakhsuvarov ishakhsuvarov moved this from Review in Progress to Work in Progress in Pull Request Progress Sep 26, 2019
@sdzhepa sdzhepa mentioned this pull request Oct 23, 2019
4 tasks
@sidolov sidolov changed the base branch from 2.3-develop to 1.1-develop December 5, 2019 22:59
@m2-community-project m2-community-project bot moved this from Work in Progress to Review in Progress in Pull Request Progress Dec 5, 2019
@sidolov sidolov changed the base branch from 1.1-develop to 1.1-develop-legacy January 27, 2020 21:47
@sidolov
Copy link
Contributor

sidolov commented Jan 27, 2020

Hi @aleron75 , due to changes in the repository structure (Magento core code is extracted from the MSI code base) we have changed the base branch to 1.1-develop-legacy. We will keep this branch for a while to make a smooth transition, in the meanwhile, please, apply changes from the current PR to the new code base structure in 1.1-develop branch.

Installation Guide may be helpful for local project development.

Let me know if you need help or have questions!
Thank you for your collaboration!

@sidolov
Copy link
Contributor

sidolov commented Feb 10, 2020

Hi @aleron75 , We are about to complete the MSI project and current issue is out of the planned scope. I'm closing the PR since the feature postponed and moved to the internal backlog.
Thank you for collaboration!

@sidolov sidolov closed this Feb 10, 2020
@m2-community-project m2-community-project bot removed this from Review in Progress in Pull Request Progress Feb 10, 2020
@sidolov sidolov deleted the MSI-1486-rework branch February 20, 2020 17:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants