I'd like to implement a Permissions API into Treasury.

I'm very interested in what anyone has to say about this, since this is the perfect opportunity to create a great Permissions API.

I'm unsure when this will be added, and the Economy API is heavily prioritized over this.

There have been a few ideas going around of improving Treasury through means which are inaccessible to Treasury's current minimum requirements of Java 8 and Minecraft 1.7.

The following is my opinion of course, please comment below if you would like me to amend this in any way.

I'm interested in hearing what you all think.

Changing the minimum Minecraft version

I'll call these Minecraft versions 'major': 1.7, 1.8, 1.12, 1.16, 1.17 - they are used by lots of people relative to the other versions.

1.7

• 🔴 1.7 is very old (2013!) - difficult to support
• 🔴 Requires a little tinkering to work with newer Java versions
• 🔴 Almost all of these servers run Java 8
• 🟢 We don't loose potential users from back this far

1.16

• 🟢 1.16 is recent (2020) - easy to support
• 🟢 Works out of the box with the latest Java versions
• 🔴 A handful of 1.16 servers still run Java 8
• 🟢 Almost all of our potential users are in this margin

1.17

• 🟢 Latest version as of writing this (2021) - easy to support
• 🟢 Works out of the box with the latest Java versions
• 🟢 All servers run Java 16+
• 🔴 We still have most of our potential users in this margin, but we loose a noticeable chunk by removing 1.16 support

Changing the minimum Java version

8

• 🟢 LTS version, easy to obtain
• 🟢 We don't lose any users
• 🟢 Works with all server versions out of the box
• 🔴 We can't use any of the shiny newer Java features
• 🟢 Every server runs at least this version

11

• 🟢 LTS version, easy to obtain
• 🔴 We lose the Java 8+ users
• 🔴 May require tinkering to get working with older servers
• 🟢 We gain almost all of the new Java features we are interested in
• 🔴 Was never a required version by Mojang

16

• 🔴 Non-LTS version, more difficult to obtain
• 🔴 We lose the Java 8+ users
• 🔴 Requires tinkering to get working with older servers
• 🟢 We gain all of the new Java features we are interested in
• 🟢 Required for 1.17+ servers

17

• 🟢 LTS version, easy to obtain
• 🔴 We lose the Java 8+ users
• 🔴 Requires tinkering to get working with older servers
• 🟢 We gain all of the new Java features we are interested in
• 🔴 Was never a required version by Mojang

Tend to the points raised in the Spigot thread. As of writing this I don't have time to sort them out yet, need to make sure they don't slip past. :)

@MrNemo64, what do you think about this idea? I believe there should only be bank members, but of course each bank member can have different permissions.

Use MicroLib's async update checker.

One of my recently updated plugins uses a special update checking class, I'll take a look at that.

I've started doing javadocs and stuff, and I got to start documenting the currency conversion system.

The currency conversion design flaws I've seen so far

1. Using hash codes
2. Requiring a registration, even though it still needs a currency conversion to be passed if you want to convert a specific value

In my opinion, this API shouldn't exist at all. I mean, if you want to jump through currencies, there should be another way to do that.

As for the currency interface: it shouldn't be an interface after all, but rather an immutable object which holds the data this interface holds, and some sort of a CurrencyFormatter interface and some sort of a CurrencyStartingBalanceGetter or something.

Suggested by @MrNemo64.

See this reply on SpigotMC.

Address concurrency using CompletableFuture so that, in the event data is not cached, a plugin won't freeze the server (if it's designed properly) whilst the economy provider fetches the data from its database.

Any commands Treasury has which work with its own APIs should be categorised.

For example, /treasury migrate should instead be /treasury economy migrate.

I would also like to split the part of /treasury info which provides information about the economy provider to a separate command, /treasury economy info. This command would also be able to tell more information since it isn't restricted by all the other information the other command has.

I am unsure whether /treasury info should become /treasury plugin info or not. I am currently quite against that but if anyone else thinks it's a good idea then let me know below

Tasks:

• Move /treasury migrate to /treasury economy migrate
• Create /treasury economy info
• Remove the economy provider information from /treasury info
• Update permissions in plugin.yml and the Wiki page

Title.
Cleans up the code more.

See #53 (comment)

Will work on this after #53 is merged.

As said by @MrIvanPlays here, just by adding the @NotNull anotation we don't ensure that a parameter won't be null

the plugin is going to be build and deployed to maven repositories via a CI and not by intellij/human, so if you want that code to generate not just if you compile via intellij, you need to find a maven plugin which does it and put it. But that has nothing to do with this PR.

This means that a null parameter could be provided when non null parameters were expected, in this case the EconomySubscriber should failt but the only FailureReason that could be provided is OTHER_FAILURE, as there is no failure reason for null parameters
This is why I propose to add a NULL_PARAMETER failure reason
The other option would be to find a maven plugin that allows us to have the @NotNull anotation actually check the parameter but in my opinion, we should avoid using others plugins when necessary

The Spigot page is outdated at the moment. I want to edit it to make it more accurate and concise.

-snip- see Spigot page. This GitHub issues page is no longer updated with the content of the Spigot page.

Please propose any changes to this page below. Still work-in-progress.

Tagging users who may be interested: @MrNemo64 @MrIvanPlays @Jikoo

Please see #37 which is an in-progress resolution to this issue.

I never liked Bukkit's command framework. Especially that since 1.13 we have brigadier and still can't use its features by plainly utilizing the bukkit/spigot api.

That's why I suggest using cloud, and particularly cloud-paper. It adds up 1 more layer on top of brigadier and bukkit's command system, allowing you to create custom arguments and much more. Don't worry - if you decide to support versions under 1.13, it will fallback to registering commands with bukkit.

Currently the Javadoc format follows a pattern: author - see - since - description - parameters - throws - return
This format creates the problem that JavaDoc genertors think that the description is part of the see tag, we can see this by generating the javadoc.

Another problem with it is using formatting options that don't exists in the JavaDoc like `Marked` This JavaDoc was generated using the java 8 jdk

The methods in EconomyProvider such as hasTransactionEventSupport can be replaced with a single method returning an enumset specifying a list of things that the economy provider supports: getSupportedFeatures

This is an issue, because if we were to add new features to Treasury and thus add new 'has..Support' methods, then older api-versions won't have this method overriden, I assume causing a NoSuchMethodException.

Since the enum can expand over time, and plugins can assume any unlisted constants are unsupported, it's all solved!

• submit request to CodeMC Discord (at 21st Dec 2021)
• receive response to request from CodeMC director (accepted!)
• set up auto-deployment scripts
• test

Instructions

Add these settings to pom.xml

<distributionManagement>
    <repository>
        <id>codemc-releases</id>
        <url>https://repo.codemc.io/repository/maven-releases/</url>
    </repository>
    <snapshotRepository>
        <id>codemc-snapshots</id>
        <url>https://repo.codemc.io/repository/maven-snapshots/</url>
    </snapshotRepository>
</distributionManagement>

Add commit status

Follow instructions here.

Automatically build

Follow the instructions here.

Create Maven job

Follow the instructions here.

Deploy to the CodeMC Nexus

Follow the instructions here.

We can use ServiceRegisterEvent to check when one has registered, then just run some logic.

As recommended in this reply by [Geolykt]((https://github.com/Geolykt), the license needs to change to a simpler, permissive one. I'm thinking MIT. Awaiting feedback on this.

See discussion here.

This is currently being worked on by @MrIvanPlays and I.

• fix formatting of existing javadocs
• add missing javadocs

See d3b7b44#commitcomment-61570889

@MrNemo64 suggested the following method: public Collection<BankTransactionEntry> getTransactionHistory() { ... }

Will expand on this issue later. If anyone has thoughts on this issue please drop them below :)

About

An Economy Adapter is a separate API from Treasury's main economy API. This API will allow a plugin to use one dependency which will automatically use Treasury or Vault on a server, with very similar methods to Vault's. This will make it extremely easy for a plugin to support Treasury, if it is already too difficult to add direct Treasury support.

Of course, using Vault, the Economy Adapter will be forcefully limited to only being able to offer Vault's Economy API's features since Treasury has them all anyways.

This issue was suggested by Jikoo with this post:

I would probably want a generic utility supporting Treasury, then falling through to Vault/whatever else pre-written for me to consider adopting it, honestly. This might even be your best bet for wider adoption - a really well-written plug-and-play utility would remove a lot of the horribly janky "definitely optional dependency" handling I've seen from people (myself included, shame on past me) adopting Vault.

The Economy Adapter will also do some inherent improvements to Vault, e.g. forcing the use of UUIDs wherever Treasury does.

A crucial change in this API is that non-player accounts (in Vault this is Bank Accounts) must require an owning member as Vault's API requires this.

Developer thoughts wanted

I'd like to hear what other developers think about this suggestion, and especially if there are any comments on my plan.

Explanation of choice of labels

• thoughts wanted
  • Interested to hear what you all think about this. even if it's just a thumbs up or something :)
• unassigned target version
  • no idea when I will work on this.
• status: on hold
  • the economy API needs to be finalized before I will start working on this. See #100

Make the Currency ID an UUID, it fits better into the Minecraft Plugin world.

See discussion here.

Unlike vault, Treasury provides multi-currency support. Given that this multi-currency support is a thing in the backend, API users may be tempted to expose currencies to the frontend. Implementing /balance is implemented easily, albeit expensively by iterating over each and every currency and doing other trivial operations. However commands such as /pay would be a lot more complicated to implement as now you'd have to parse the amount.
It is rather easy if you have a syntax that operates like /pay <reciever> <amount> [currency], where as currency has to be a currency name; easy enough to implement given that the currencies name can be looked up easily via Treasury API. However what if the User wants to format the amount to something like 15€? As far as I see there is no sane API to resolve that currency. The same applies to $ 15, $15, 15 USD or 15 €. An API user would not like to do this parsing hell manually so I propose an API to allow parsing strings such as the previous examples. This is aided by the fact that Currencies are only provided by the economy provider, so 3rd party currencies would not prove to be much of an issue.

What would the best course of action be here?

Aside from it being an magic value, the only location where an API version is defined is in Treasury#apiVersion, which just makes the problem worse especially because it's visibillity would allow the developer to return said value without a problem.

I thus propse to have some way of obtaining the API version for version X of the plugin. This can be done similarly to how Objectweb ASM does it, i. e. define a constant (let's say TREASURY_API_EXPERIMENTAL and TREASURY_API_1) in the EconomyProvider interface, though I don't have anything against having it be located in a different location. All things considered the current way of doing it is suboptimal

To-do list for release

• Need to finish documenting things like transactions etc.
• Need to provide examples of how to use the API.
• Add updating instructions to the installation page.

To-do list for the future

• Explain the internal design and workings of the library, e.g. accounts, currencies, and so on.

I'd like to implement a Chat API into Treasury.

I'm very interested in what anyone has to say about this, since this is the perfect opportunity to create a great Chat API.

I'm unsure when this will be added, and the Economy API is heavily prioritized over this.

What's the purpose of bank owners compared to bank members? Should we only have bank owners or bank members? Or should both exist?

Suggested by @Geolykt. Will first resolve #25.

Hi all,

I have finished my comparison of Vault, Reserve and Treasury on this Wiki page. Please tell me if you disagree with anything, I am only looking to make an accurate comparison.

I'll close this issue if there is no activity for a certain period.

Tagging users who may be interested:
@Jikoo @MrIvanPlays @Geolykt @MrNemo64 @NoahvdAa

It simply doesn't feel right working with Strings when the whole selling point of the API is that it is using persistent UUIDs.
Also changing the world name changes the world name, but keeps the UUID, so linking it to an UUID would be better than linking to a world name.

Oct 10 21:14:21 <Geolykt>	is there any disadvantage of storing a world by name instead by it's UUID? And would renaming a world also change it's UUID?
Oct 10 21:15:28 <DiscordBot>	<C​ry​pt​it​e> So aside from one first-time world hiccup thing... this seems to work: ((CraftPlayer) p).getHandle().smoothWorldTeleport = true;
Oct 10 21:15:36 <DiscordBot>	<C​ry​pt​it​e>  https://cdn.discordapp.com/attachments/555462289851940864/896838389922431057/SeamlessTP.mp4
Oct 10 21:17:00 <phoenix616>	renaming doesn't change the UUID, that is stored in the level.dat
Oct 10 21:17:27 <DiscordBot>	<H​ex​ed​He​ro​> disadvantage is that owners could change the world name
Oct 10 21:17:58 <Geolykt>	So just what I thought.
Oct 10 21:19:11 <DiscordBot>	<e​le​ct​ro​ni​cc​at​[n​o-​pi​ng​]> for persistence you don't want people to touch, I often store both, and prefer uuid and then name (but, honestly, I rarely care to add that fallback)
Oct 10 21:19:11 <phoenix616>	technically it's also an advantage, really depends on what your goal is
Oct 10 21:19:32 <DiscordBot>	<e​le​ct​ro​ni​cc​at​[n​o-​pi​ng​]> config files and such often use names because, well, people can actually see them
Oct 10 21:23:03 <Geolykt>	Well, in this case It's developer API stuff, UUID makes more sense then

(#paper-dev @ irc.esper.net)

Right now the EconomyAPIVersion class is really simple: Identifyes mayor versions with a number, not more not less. I think this should change. I propose some changes

1. Change the use of the @since tag, instead of @since v1.0.0 we could use @since {@link me.lokka30.treasury.api.economy.misc.EconomyAPIVersion#VERSION_1 v1.0.0} in the documentation shows the same but it provides a link to the enum version
2. Change enum entryes naming, instead of VERSION_1 we could use v1_0_0
3. Specify an order. All enums implement the Comparable<> interface with the default logic being indexes. Since this logic doesn't necesarily apply to us it would make sense to specify out comparing logic
4. Change the number system. Using integers to know what version it is means that we can only represent big updates, we could have an array of ints/shorts/bytes (probably shorts is enough for all versions we may release)
5. (Optional) in de documentation of each entry list the changes of that version

I can make a class with this features so you see what I mean

I believe this was discussed in #37.
This issue will be on hold until #37 is completed.

I haven't used modules before, I might need pointers here. I'm also very interested to hear what modules developers think Treasury should have. I'm thinking:

• treasury-api
• treasury-plugin-bukkit, treasury-plugin-sponge, etc

About

I'd like to add a Protection API to Treasury. This involves adding simple methods to check if a Location is within any Protection plugin's claims.

What are Protection plugins?

Protection plugins prevent a certain location from being modified by players, such as building there, interacting with blocks, entering the location, and many more checks are done by all of the different Protection plugins out there. These plugins are WorldGuard, ClaimChunk, TownyAdvanced, PlotSquared, Lands, and so on.

Developer thoughts wanted

I am interested in what other developers would like to see in this Protection API.

On hold, unknown target version

I'm prioritizing the Economy API to be fully completed before I consider working on the Protection API. I don't know when it will be added after that happens.

Requires #6.

See discussion here.

This module would feature stuff such as gson serializers for Account, NonPlayerAccount, PlayerAccount, Transaction and Currency.

I don't think such stuff shall be part of the general API as not every economy provider will choose to support gson for storage or would like any of these enhancements.

Another names for this module I can think of is api-enhancements or api-extensions or api-qol-utils if you do not agree with the name I suggest.

This is a low prio issue, not really important, I'm opening this for discussion.

Before v1.0 is released to Spigot, it must be tested. The following checklist will be edited as testing proceeds.

Currently this issue is on hold since the plugin is not ready for testing - it is still in development.

• Test startup and shutdown (no errors?)
• Test the update checker (ensure to force-enable it in the code, use a different resource ID since Treasury doesn't have one yet)
• Test the settings.yml file (toggle the update checker, see if that functions)
• Test /treasury commands
• Test the messages.yml file (change some subcommand messages, see if that functions)
• Test the migrate command fully with two or more economy providers.

The API is highly likely to work, and it is currently too difficult to test, so any bugs found after release will be promptly resolved.

The .gitifnore file is an important part of a git repository, how ever the .gitignore of this repository doesn't cover all files. Since it only contemplates Intell Idea, contributors using other ides will have trouble. I propouse using a more extense file, there are good generators online that can do the work, for example, this would be a .gitignore template for Intell Idea, Eclipse, Java and Maven

I have no experience using CompletableFutures yet. I also don't think the migrate subcommand has been seen by anyone, or at least commented on. So I think it would kill two birds with one stone if anybody could kindly assist me in updating MigrateSubcommand.java to use the new CompletableFuture methods (which your IDE should highlight as errors).

Cheers :)

Edit:
After the discussion here, I feel like the hasXSupport methods are a bad idea and I would actually like to see Treasury drop the idea of not implementing the entirety of its interfaces.

It really doesn't make sense to me to have 50% of the methods be designed to not be implemented. Anyone who does offer Treasury support should be able to offer bank support with minimal extra work due to how similar the accounts are.

If we do truly want a method to check for support that should likely just be rolled into the API version system, not the provider interface(s). The javadocs for each method state the API version it was added in and the provider states the API version it was programmed against.

Original writeup:
I would like to see EconomyProvider separated into several interfaces.

As a developer, it makes it a lot easier to work with player/bank accounts if I know exactly what is available to me rather than constantly re-checking if banks are supported and whatnot.

As a server owner, the increased granularity makes it possible to invent a solution that more exactly suits my needs by selecting the exact bank and player account implementations I want.

• TreasuryApiProvider
  • Provide Treasury API version implemented, owning plugin
• CurrencyProvider extends TreasuryApiProvider
  • Provides currency definitions and handles parsing
  • Should define currency management (creation, deletion, modification, etc.)
  • Treasury should probably implement and provide at ServicePriority.Lowest
    • See #40
  • Definitely needs improvement, but outside the scope of this issue
• AccountProvider extends TreasuryApiProvider
  • Provides a requestCurrenciesInUse or similar method
    • Allows CurrencyProvider to support undefined currencies, making migration easier.
• PlayerAccountProvider extends AccountProvider
  • Provides PlayerAccounts
• BankAccountProvider extends AccountProvider
  • Provides BankAccounts
  • Methods should not clash with PlayerAccountProvider
    • Makes it possible to create a generic MyEconomyImpl implements PlayerAccountProvider, BankAccountProvider to mimic Vault style interface usage