blocked RFID / OCCP User about steve HOT 5 CLOSED

more info about the request needed

from steve.

If a user authenticate with a RFID-Card which is not registered, then ignores SteVe this Event and send only an blocked to the charging station.
But it is nice the new RFID Card is registered, but the entry is blocked. So can the support set free this Card.

from steve.

oh ok, this is a nice suggestion and would make the job for the manager (user of steve) definitely easier. however, i would like to ask the community some questions, though, before implementing this feature (which is not much work btw) :

1. are there any other ideas, different perspectives about this idea that others wish the implementation would cover? i am asking this mainly so that the implementation can be done once and for all, and it supports more use cases.

2. this is more of a concern: what about flooding the database table with lots of rfid entries, which would end up being junk? in reality, anyone with any card (and i literally mean any) can go to a public charging station and try to authenticate. these probably might be customers, but also people trying things out just for fun to see what happens. as long as the rfid reader of the charging station can read the card, it will ask steve about the registration. so, there might be many blocked rfid entries in database, which are of no use and have to be manually deleted (if the manager wants to, because otherwise clutter, noise). and because of that, the following question arises: is it easier / better / less work to register rfids beforehand, or to delete junk rfid entries later? if you have that many blocked rfids in database, how will you know for sure which rfid to unblock?

3. in addition to the last point, how to differentiate between the actual blocked rfids due to the business cases (e.g., the contract ended or the card was lost / stolen) and rfids inserted into db as blocked after an auth request? to be clear, the latter is not an "rfid that is blocked" in the true sense, but rather an "rfid that arrived which might be a customer". this situation suggests to store these entries somewhere else (temporary table?) which then can be manually moved to the actual rfid table. and then we face the same question as above: is it easier / better / less work to register rfids beforehand, or to take this additional step later?

are the concerns of 2nd and 3rd points valid? how can we overcome these? or should we neglect the probability of such things happening?

from steve.

I think the suggestion is valid, cluttering the database seems not an big issue for me, as it creates ~1 row per real-life action. UI-wise it should be enough to only show the n last ones. To distiguish unknown id's the timestamp can be used.
Obviously bulk registering RFIDs beforehand is better, but in some scenarios that might not be possible.

from steve.

the point three is interesting. Maybe another name for the flag of new rfids records.

from steve.