I don't think we need extra check. All we can do is to throw another
exception..

I believe the `can` method is more useful when dealing with UI, it can tell
us what buttons we should show.


On Fri, Apr 25, 2014 at 3:49 PM, Alexandre Bacco
<notifications@github.com>wrote:

> In src/Sylius/Bundle/CoreBundle/EventListener/InventoryUnitListener.php:
>
> > -                $unit->setShippingState(ShipmentInterface::STATE_ONHOLD);
> > -                break;
> > -
> > -            case $unit::STATE_SOLD:
> > -                $unit->setShippingState(ShipmentInterface::STATE_READY);
> > -                break;
> > -
> > -            case $unit::STATE_RETURNED:
> > -                $unit->setShippingState(ShipmentInterface::STATE_RETURNED);
> > -                break;
> > -
> > -            default:
> > -                throw new \InvalidArgumentException(sprintf('Unexpected inventory state "%s".', $state));
> > -        }
> > +        $this->factory->get($unit, 'sylius_inventory_unit')->apply($transitionName);
> > +        $this->factory->get($unit, 'sylius_shipping_unit')->apply($transitionName);
>
> Yes for sylius_shipping_item, don't know how this unit fell here.
> Regarding the check, this is indeed something we need to decide. But
> anyway, this particular listener will be so useless thanks to some events
> on transition!
>
> Btw, side question, is this ShippingItem::getState usefull? I see it just
> reflects the parent shipment state... The only state that could differ
> between Shipment and one of its ShipmentItem is returned. But is it
> something we want to track in the ShippingState? It is already tracked in
> the InventoryUnitState and this seems more logical there. I'd like to
> delete it =)
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/Sylius/Sylius/pull/1426/files#r11986029>
> .
>