In order to view both Server and Client perspectives, on the Play dropdown, set the Number of Clients field to 2.
In order to create properly networked gameplay through Blueprints, it is important to also understand the concept of Network Relevancy. Simply put, it often does not make sense for a client machine to have to receive network data for every Actor, all of the time. A player on one side of a large map does not need to know everything occuring on the other side of the map from a networking perspective. In that case, we say only some Actors are "relevant" to the player at a given time. Relevant Actors are usually the ones players can see, interact with, or are nearby. The player receives full network updates only for relevant Actors, as an optimization.
One side effect of the optimization is that one also has to consider how to handle the case where an Actor was irrelevant and then becomes relevant (usually as a result of the player moving nearby). This is very similar to the problem of handling a player who joins an existing game-in-progress.
This example, and the rest of the Network Relevancy examples, lead to reproducing the behavior of a chest opening taking into account relevancy.
Blueprint Breakdown
In the BP_Relevancy_Replication_None Blueprint's Event Graph, you can see that when the authority recieves the signal that someone has overlapped the trigger, the OnChestTouched function is called and executed only once by the DoOnce node.
Click for full view
The OnChestTouched function then executes two additional functions: one for opening the chest and another for playing effects that are tied to the chest opening.
Click for full view
Since the example does not attempt to handle replication or relevancy, only the Server can see the chest opening.