I read that it is not correct to connect more than one primary actor to a use case so a situation like the image below is not correct
So I used inheritance like this
But the use case has an extended use case that is for only one actor (the second actor does not have that extended use case).
So in my example both manager and HR can browse users but only the manager can block a user.
How can I represent that in the diagram?
Two (or more actors) connected to one use case mean that all actors are involved in this use case. If you want to show, that either one of multiple actors can be involved, a generalization is a good possibility.
The notion of "primary" actor is not specified in UML. Therefore, I talked about actors involved in a use case. Of course, in the description of the use case you will be clear about which actor initiates the use. This will be the primary actor.
All the problems you have with «extend» can be solved by simply omitting it. In my opinion «extend» doesn't contribute to a better model. If you want to say that there is an overlap in the description of several use cases, you could use «include». But actually, you should not worry too much about these relationships. After all, you want to describe what actors are using the system for. Each actor goal is an own use case.
I'm with Axel: stay away from «extend» unless you know what it's meant for. I would guess that in your case it's legit. So what you can do is to just add a constraint to either the extend relation or to the actors explaining the restriction. Simply show it as a note with the constraint { in curly brackts}.
Otherwise there is a convention to put primary actors (the one that triggers the UC) to the left and involved actors to the right. Your approach with generalization is just fine. An actor represents role (like in a screenplay). And identifying those roles is an essential part during UC synthesis.
As always I recommend to read Bittner/Spence about use case modeling.
This notion of "primary" actor is not in the latest (2.5.1) version of the UML Specification. You just associate the right actor/s (Manager, HR or both) to each of your use cases without using generalization (inheritance).
