You have basically 2 options.
Use one UC with eventually different scenarios (prefered in my opinion). In this case you have only 1 UC and all actors connected to it. As each actor has special conditions, simply make 3 different scenarios for each actor and depending on the actor decide which scenario to use. You can also use only 1 scenario and cover all the rules within it. This is even better choice, if the differences are relativelly small and easy to structure and define in a single point in scenario.
Use different UCs. You can alternativelly use a main UC and then derive 3 special use cases. Each actor gets "his own" use case. Main UC defined the main scenario, the geenric part of it (maybe just the squeleton) and 3 sub-usecases define their own special reqs.
There is also a third option, kind of mix, with the application of include-relationship (note, it's NOT extend). I find is kind of misleading though and too complicated (4 use cases, relationships).
For the same reason, I would suggest the 1st option. It discovers the main point of the use case (view list) and the fact that all 3 actor can use it. On the other side it surpresses the detailed rules to the inner-description of the element. Nice use of abstraction, the main modelling principle.
Here both diagrams: