trebol-ecommerce / trebol-backend-monolith Goto Github PK

Specially useful at the JPA perspective, the Optional pattern can prevent null pointer exceptions when certain data does not exist or cannot be found.
It does enforce an stricter and more recurrent persistence check, but I'd raise the quality of code and lower the chances to raise unexpected exceptions, instead of lowering the amount of lines of code.

To implement this, every property and method marked with @nullable should be refactored to type Optional.
Then, on each reference to those properties/methods, instead of arbitrarily adding != null conditions, there must be a .isPresent() check and then return .get().
Make sure to raise typed exceptions or return Optional.empty() at applications levels other than JPA, when needed .

In the API spec v1.1.2 the following resources must be reviewed

• /data/customers
• /data/images
• /data/people
• /data/product_categories
• /data/products
• /data/sales
• /data/salespeople
• /data/shippers
• /data/users

These must support all of the following query parameters:

• sortBy
• sortOrder
• pageSize
• pageIndex

This logic is not implemented in any controllers.

In recent changes to the codebase, the interface IPredicateJpaService was introduced to parse query parameters into filtering conditions. A similar interface could exist to parse them into sort orders. It should make use of the Pageable interface, through method calls with QueryDSL classes (e.g. QCustomer) and Sort.by().

Gotta love people who help fellow peers like me to develop software!
Here's to Trang Nguyen for sparing time and effort to clean up issues during Hacktoberfest this year. Hope you go to far places in your career!

Name filter is not working

Beginning API v1.1, the Receipt model features new properties:

• token - A unique code identifier of the entity. A 25-char long hash of itself, calculated at checkout time, is good enough.
• taxValue - The amount of money destined to taxes. Can be 0 until a decent algorithm for it is figured out*
• transportValue - The amount of money for transporting.
• totalValue - The sum of all amounts above and the netValue.
• totalItems - The sum of all product units held in the transaction.

Currently, under the hood, Receipt are actually Sell entities with less metadata.
So these properties must be added to Sell API/POJO and JPA/Entity classes.

*The tax formula needs to be quite abstract - each country may have its own taxes formula, and any number of factors may need to be taken in account.

Sometimes, it'll be wiser to use a fallback database engine. The following must be done for that to happen:

• Include h2 dependency in pom.xml
• Add some initial/mock data to work with (Spring Data supports inclusion of a "data.sql" script)

I want to address two things here.

• The license file indicates the year is 2020. I'll put a year range instead.
• Most classes I've created using NetBeans in the past have been given some javadoc lines indicating I'm the author of them. This isn't really an important matter, but it does add bloat to the codebase without any reason or meaning behind. Any mention of my specific name will be removed entirely. After all, anyone interested in this project is bound to know how to reach out to me. I don't hide myself.

I got to develop some unit tests for the first time and I've gotten around 25% of the codebase.
This link provides better insight on this.

The packages with utmost importance to be covered are:

• org.trebol.jpa.services.conversion
• org.trebol.jpa.services.predicates
• org.trebol.operation.services

Originally posted by @bglamadrid in #22 (comment)

When I started creating the JPA @Entity classes in this project, I was using the NetBeans IDE templates which come with some default annotations. After some study, I've come up with some change proposals to be made to all @Entity classes:

• Remove @Basic(): used mostly for setting non-nullable columns, but @Column(boolean optional) fulfills the same purpose on schema generation and data validation
• Remove @NamedQuery(): custom queries is a matter handled much better with Spring Data JPA and QueryDSL
• Remove redundant properties from annotations e.g. if having @JoinColumn(updatable = true), remove the updatable property because the default value is true
• Also, make sure all serialVersionUIDs are different

It should just check for compilation errors for now.
#22 would be much more useful with this.

Trébol hasn't yet been published.
Instead of cl.blm.trebol, I feel org.trebol is a better fit for the philosophy and intentions behind Trébol.

As stated in the README.md file, this project supports any relational database that has support for JDBC.

Other database vendors may be used as well.

• Apache Derby
• MySQL
• SQL Server
• PostgreSQL
• DB2
• Oracle

The problem

I'm not sure if all their drivers are licensed under MIT or a similar open-source license.

For example, I know that Oracle drivers are not licensed to be freely distributed under foreign projects: if you want to use Oracle, you have to get those drivers on your own from their site.

THIS ISSUE NEEDS RESEARCH, DISCUSSION AND RELIABLE PROOF BEFORE ANY PULL REQUEST IS MADE.

Company name, logo, etc

Currently products are including an empty array

When a user tries to delete any account using the Data API, if the target account is their own, the action should be denied.

Product categories now have a complete CRUD specification.
It must be implemented all in one path: /data/product_categories, following convention like in #64
This also means deprecating the existing /data/products_categories/{parentId} mapping too.

Fortunately most of the job is already done; there is a fully-fledged ProductCategoriesJpaServiceImpl service written already.

Also the application.properties must be updated with the correct CORS mappings, and security rules applied in SecurityConfig class.

Like the Receipt entity itself, ReceiptDetail is a target of changes in the latest API roll-up.
Under the hood, ReceiptDetail entities are just SellDetail. These entities must now include a unitValue property, that must be the same as the price of the Product they hold at the time of checkout. This applies for both the API/POJO as the JPA/Entity side.

Should be easy enough to implement.

TrasnbankDevelopers recently released Webpay Java SDK v3.0

It's looking good! And this project should make use of the latest available version of every library it depends on.

There are people to be credited for certain concepts, ideas and solutions.
Below are names that I must partially credit for the making of Trebol

• @amigoscode for fluently describing a working example on his youtube channel about how to implement Spring Security auth using JWTs and a DB. I did write the implementation code on Trébol myself, but it's sooo very similar to his codebase, I feel I have to reference it https://github.com/amigoscode/spring-boot-security-course/tree/8-JTW

Add entity, POJO, repository, crud service and data controller for the following entities:

• Address (one-to-many for sales, twice; shipping + billing)
• BillingCompany (one-to-many for sales)
• Shipper (one-to-many for sales)
• PaymentType (one-to-many for sales)

Besides, apply these changes.

• SellType renamed to BillingType

Dropbox has an open-source, well-documented SDK for using their storage systems through REST calls.
This will implement #25

I'm planning to refactor the following, to avoid confusion when trying to figure out how things work:

• services/crud -> jpa/services
• services/exposed -> api/services
• services/security -> security/services
• services/user -> services
• security/pojo -> api/pojo
• services/exceptions -> */exceptions

New data types

• Address: first line, second line, city, municipality, postal code, notes
• Billing Company: id number, name
• Shipper: name
• Sell Status: code, name
• Payment Type: name

Changes in existing data types/resources

• Person does not have an "address" property anymore.
• Person's "phone1" & "phone2" properties are string. A pattern is included and must be validated at any possible extent.
• Person's "idCard" property is now named "idNumber" and is not nullable.
• "Sell type" is named "Billing type" instead.
• The (now-called) billingType property of Sell is a string instead of an object reference.
• Sell is related to two Addresses: shipping address + billing address, both are nullables.
• Sell is related to a Shipper, a Billing Company, and a Salesperson, all of them nullables.
• Sell has new properties: date, netValue, status, paymentType.

A few changes related to products and images was recently pushed in https://github.com/trebol-ecommerce/trebol-api

These include:

• Add API model for Image; Remove property "imagesURL" from Product API model; Add property "images" of type "Image[]" to Product API model
• Add "/data/images" API resource with GET and POST methods

I got to develop some unit tests for the first time and I've gotten around 25% of the codebase.
This link provides better insight on this.

The packages with utmost importance to be covered are:
org.trebol.jpa.services.conversion
org.trebol.jpa.services.predicates
org.trebol.operation.services

Originally posted by @bglamadrid in #22 (comment)

The following paths must be deprecated in favor of the stated replacements.

• /data/customers/{idNumber} - use /data/customers?idNumber={} instead
• /data/images/{code} - use /data/images?code={} instead
• /data/products/{code} - use /data/products?barcode={} instead
• /data/sales/{buyOrder} - use /data/sales?buyOrder={} instead
• /data/salespeople/{idNumber} - use /data/salespeople?idNumber={} instead
• /data/users/{name} - use /data/users?name={} instead

Deprecation itself can be done by simply adding a @Deprecated annotation on the corresponding method mappings in the controller classes.
Then, a corresponding request mapping must be added for each new method (PUT and DELETE) of each replacing path.
This means adding a PUT and a DELETE mapping to /data/customers, /data/images, and so on...
Also, it would be good that GET requests are optimized when requesting a single item, fetching only one result if any. The IQueryDslPredicateParserService interface takes care of translating API query parameters into filtering clausules for queries in the persistence layer, and all descendants of GenericJpaService implement it.

Calling /store/checkout does nothing.
According to the API documentation, it receives an array of SellDetail (in this case, SellDetailPojo).
It must

• Validate the user token
• Retrieve the associated Client
• Calculate total cart value
• Insert a new Sell into the database associated to the Client, with a 'pending payment' state
• Call the selected payment SDK, to initiate the transaction
• Send the details so the client can be redirected to the payment

Using ResponseEntity is a great way to write controllers down as if they were API documentation, with declared HTTP response codes.

Since v1.1, Shippers have their own CRUD operation set.
It must be implemented in /data/shippers, following new conventions set by #64

A descendant of GenericJpaService, as well of GenericDataController need to be created for this. Following examples set by the rest of classes doing the same should suffice to make this work.
Also the application.properties must contain the correct CORS mappings, and security rules applied in SecurityConfig class.

SonarCloud is a platform built on top of SonarQube for the cloud. Supports Java and is free for open-source projects such as this. Gotta figure out its similarities with Travis CI and enabled testing scopes though, see if it supports building pull requests etc

Adding specification and initial contributors

Currently running 2.3.4-RELEASE

While the API documents what resources can a user access, there are application logic rules that apply beyond the scope of the API alone.

• A user should not be able to delete his own account
• #98

Every rule should generate a new issue.

This is kind of a breaking change.

From latest changes in the API, the Person model split its name property into two, firstName and lastName.

This change must be reproduced both at API/POJO and JPA/Entity levels.
Customer and Salesperson are directly related to Person, so they will also need an overhaul. Both entities' data can be filtered using a single name parameter, however. This must remain in a working state.

Yep, I forgot to add one. The @Entity classes themselves already can generate a valid database schema.
So I'm thinking of using Adminer connected to a MariaDB instance for designing this. Should be done in a breeze once I get time to do it.

This project has almost no tests at all. To start somewhere, some unit tests should be written.
Given that this backend is powered by Spring Boot's dependency injection features and the such, tests should conform to adequate practices in order to execute as expected.

Tests are required at least for the following components:

• REST Controllers
• Exposed Services (consumed by REST controllers)
• Security Services
• CRUD Services

Before writing tests on a class, a specific issue should be created for them, so acknowledge it is being worked on.

Said services can be external, each one may behave and integrate differently. Nowadays, a path must be created for images to be stored somewhere, their references saved in a database.

They should return a JSON object with customer roles, or at least an empty object.

After resolving #70 , there is a new step to be taken before removing deprecated paths, and it is making their replacement available to the public.

This means that the path/data/product_categories must be made available to all users, not only authenticated ones.

The controller mappings themselves have an annotation @PreAuthorize that should be removed for this.
Also the SecurityConfig class must be updated to match this.

Since Transbank Developers keeps an up-to-date SDK to integrate their payment services, it's a far better choice than dealing with HTTP REST calls by hand.

The following paths are to be deprecated and later on, removed entirely:

• /public/categories
• /public/categories/{parentId}

Both of them perform exactly the same as /data/product_categories.

Deprecation itself can be done by simply adding a @Deprecated annotation on the corresponding method mappings in the controller classes.

Properties are meant to be configured at higher levels when deployed in cloud environments. Thus, having many property sources would make things confusing

Here I am following suggestions and guidelines stated in https://keepachangelog.com
Starting from Trébol v1.0 I should be putting some effort into keeping an orderly, human-readable change log.

According to the API documentation, it receives an instance of User (UserPojo, in this case) including full profile details (a PersonPojo).
In order to create new user accounts, it must:

• Validate the input user object; email must be valid, required data must be supplied
• Verify the username is not already in use
• Validate the profile does not exist; there cannot be two user accounts for the same person
• Encode/transform data to JPA entity counterparts
• Save entities into database and return a successful response

When creating new users using the Data Management API, their role must be specified.
The accepted roles should be fetched by querying an API route such as /data/user_roles, and access to this route should be very restricted.

Trébol could be implemented with others technologies just as fine as with Angular/Spring Boot, so I'd like to have a specific naming scheme for the repos that make up Trébol's core itself.
This one should be named "springboot-backend", and its maven package should reflect on that as well.

As the subject says, it is important to have the basics covered for all service classes within the package

org.trebol.operation.services

This issue may be blocked by future refactorings, nonetheless it will remain here as long as it doesn't have at least 60% code coverage.

Some annotations such as JsonInclude, JsonIgnore, JsonProperty can be shortened using static imports.
The aim is to increase readibility on these POJOs, which should be the simplest of all classes in the source code.