What relationships should be there between:
Well, it is hard to tell from what info you give us. Maybe you want to capture which instance of an admin created an item. Then you should name the association end creator. That an admin manages all classes doesn‘t mean that the admin class must have associations.
An order item references an item, so, there should be an association instead of a generalization.
All the rest of the shown relationships should be regular associations. The white diamond you use denotes a shared aggregation and is almost always superfluous and only confuses the readers.
All associations should have multiplicities and could have role names at their ends, which would make the diagram much more meaningful.
This is an interesting start. In addition to Axel's answer, and considering your revised diagram, I'd like to provide you some means to find issues by yourself:
Cross-check systematically all the multiplicities. You do this by first imagining an instance on one side an see with how many instances it can be associated with on the opposite side, and then do the same in the opposite direction.
Take the example of Item and Order_item: take an order item, it is clear that it must refer to an item and can only be associated with one item. So 1 (which is equivalent to 1..1) is correct. But in the opposite direction: are you sure that an Item can be ordered only once? That there can be at most a single order_item?
Make sure that optional associations are optional. So cross check multiplicities with a minimum cardinality greater than 0 correspond to mandatory associations.
Take again the example of Item and Order_item: the admin can create a new Item X, that is not used in any order item until it is ordered a first time. So there seem nothing wrong for an Item to appear in 0 Order_item.
Take another example: Wouldn't "at most 2 tasks" mean 0..2? Or are you sure that each order must have at least one task? Only you could answer ;-)
Be extra-careful with any relation that are not simple associations. The question here is simple: if you would replace your special relationship with a simple assiciation, would you loose some critical information in your diagram?
Take the example of the black diamond: ok, if you'd remove it, you would loose the hint that an order item makes no sense without the order to which it belongs and has no reason to exist on its own. You can keep it.
But what about the white diamonds. If you would remove them, would you really lose any relevant meaning that is vital for the designer to know?
You've already removed the inheritance (withe triangular arrow head) and that's fine. Because this means that an instance on the side of the arrow head could be used whenever an instance of the side of the arrow head is expected.
Subsidiary question: do any classes in the diagram share a significant set of attributes and behavior? If yes, you can ask yourself is one isn't a specialization of the other (inheritance).
For example, is an Admin also an Employee? If yes, you may add an inheritance relation between the two, and remove in Admin what is already defined in the employee.
