Update Log 1 (3/4/18)

Thanks again for all the support for this project. I really appreciate all the great comments I have received. This is the first update log for GriefPrevention on utopian. It will discuss the bug fixes for the past 2 weeks. I plan on providing an update log every 2 weeks as long as there are enough changes to discuss.

Bug Fixes

Issue - Wrong operator '&' was used in if statement which caused a ClassCastException due to both expressions being evaluated.
```
if (user != null && user instanceof EntityPlayer & SpongeImplHooks.isFakePlayer((EntityPlayer) user) && user.getName().startsWith("[")) {
```
Solution - The & operator was changed to && to only check SpongeImplHooks.isFakePlayer if user was an EntityPlayer.
Issue - GP was not handling entities moving in and out of claims if no event context user was found. So for example, if the world spawner spawned a creeper and this creeper attempted to move into a protected claim that denied the move, they would still pass due to no perm check being done in GP's event handler.
Solution - Permission checks were added for both enter-claim and exit-claim flags.
Issue - Armor Stands were not being protected by default in GriefPrevention. This was because an Armor Stand is an Entity and interact-entity-secondary flag is allowed by default. This allowed any player to walk into a claim and right-click on an armorstand potentially stealing armor from a player. The owner of a claim did have the ability to add a flag exception to deny armor stand interaction but this still wasn't a good option for new players.
Solution - In order to protect Armor Stands by default for players, I chose to treat them as any normal chest. So when a player attempts to right-click on an ArmorStand, the inventory-open flag is checked which is denied by default in claims.
Issue - GP's SaveWorldEvent was not checking for worlds with claims disabled which caused errors to show up in logs.
Solution - A check was added at start of event handler to verify if world has claims enabled and if not to skip remaining logic and return.

Issue - Players were able to walk into any claim and put the claim up for sale by using the /claimsell command.
Solution - An owner validation check was added for the player running the command. If the player does not match the owner, it is denied as shown below

if (!playerData.canIgnoreClaim(claim) && !player.getUniqueId().equals(claim.getOwnerUniqueId())) {
      GriefPreventionPlugin.sendMessage(player,  GriefPreventionPlugin.instance.messageData.permissionClaimSale.toText());
     return CommandResult.success();
}

Issue - Before I can explain this issue, it is important to know the basics of Sponge's tracking system. Whenever a block change occurs in a minecraft world, Sponge's tracker captures the changes and sends them off to plugins via events. Part of the capture includes gathering important information of the cause and context relating to the change. For example, if a player places a dispenser into the world, Sponge will record the player's UUID as the owner and notifier then stores this into the chunk. The owner represents the creator of a block. The notifier represents the user that last notified/interacted with a block. By having this information, if the dispenser starts to spawn items, Sponge will check for the owner UUID and send off this information via the spawn event.
With that said, the minecraft mod ComputerCraft provides a special turtle block which can be programmed to do various tasks such as moving to other locations. Whenever the turtle would move to a new location, the owner information would be lost due to a bug in Sponge. This caused GP to receive the event with the wrong tracking data which cancelled the break event causing a dupe. The screenshot below shows a duped turtle.

Solution - The solution involved multiple changes across both GriefPrevention and Sponge.
Change1 - Collision checks were being ignored on top of blocks. The check was added in GP's collision handler to solve the issue.
Change2 - GP will only use the owner of a block caused by a TileEntity source. Previously, GP would only use the notifier which would work properly until an action occured, such as activating a lever, by an untrusted player causing the tracking information to be updated.
Change3 - The last change allowed newly created TileEntities to include its previous location's tracking information. For example, whenever a turtle moves, its tracking information is transferred to the new location in order for plugins, such as GriefPrevention, to handle the event properly.
Issue - GP provides the ability for claim owners to change their claim type. For example, if a user creates a town but decides he/she no longer wants to run one and wishes to change to a basic claim. However, not all claim types have the same restrictions. For instance, a town allows any claim to live inside it except another town. A basic claim only supports subdivisions to be inside it. The issue was GP was not properly checking all the proper restrictions for the new claim type which ended up causing the bug below.

Solution - A new method validateClaimType was added that checks all restrictions to ensure none are violated before changing to a new claim type.