I made the code more passive, avoiding issued at taking, returning,
storing alerts or removing alerts from an item.
Now they all check if it is with you before returning/deleting
alert etc. I am not sure if all cases are covered, but they are
better than before. I had one only issued on this on that time,
but I prefer to prioritize safety/security.
I took the opportunitie to move some code from Controllers to
the model itself, as they were changing with the DB.
It happend once: a user asked to be added to the waiting
list at the same time other user was returning the item.
So the user ended up waiting for the user he was already
using.
Some PHP version or configuration were causing this error.
On app.blade.php of local branch, I could use "$usedItems ? :"
even if $usedItems were null, but I had to check an "isset" to the production.
On HomecController, I had to change the "object" parameter of getUsername
to "\Illuminate\Database\Eloquent\Collection" to make it work.
I took the chance to just show the number of itens in use
if it were greater than 0.
It was necessary to keep refreshing the page to
check if an item was returned when we did not
want to be alerted. So, now, the page refresh
itself every 2 minutes (while I do not know how
to use Laravel broadcasting) and the title shows
the number of items in use (including when used
by you).
When we had no items showing on home page, it were just blank.
Turns out that the @empty call that shows the default message
were appearing just when it had no items on a product, instead
of no items at all.
Fixed it moving the paragraph to the right place.
On email body, it usually appeared as the button to the website
would take directly an action, so the text was changed to make
sure the user will understand he is only going to access
the website.
