[FEAT] Add requests #13

New issue

Open

opened 2026-03-22 01:10:07 +01:00 by arthur.wambst · 0 comments

arthur.wambst commented

2026-03-22 01:10:07 +01:00

Owner

NOT FINISHED at all

maybe dont bother with multiple object, just keep one transaction and add multiple columns to have the current status, know if there is a need for 'intermediate' objects ?

Instead of discussing then manually adding transactions, request transactions, that must be reviewed then accepted or rejected.

To avoid having transations that could be request or 'real' transactions, create a new TransactionRequest model.
With the same objective, remove pending transactions and create a TransactionUpcoming model

The workflow should look like :
Request -> (approved or refused) -> TransactionUpcoming -> (after buying / receiving the money) -> Transaction

The accountant/roots will be able to create request, upcoming and transactions, whether it is linked to a project or not.
Meanwhile, clubs/members will be limited to requests creation, which must be linked to a project.

Roots will be able to generate estimates (devis) from TransactionRequest (when they arent refused), and invoices (factures) from TransactionUpcoming (anytime? or only when not validated?)

Reduce transaction types to:

EXPENSE
INCOME
FUNDING (or maybe remove it ???? idk)

Create a new filed for transaction with enum TransactionStatus :

Requested (color for front: light blue)
Refused (light red)
Upcoming (blue)
Cancelled (red)
Done (green)

col to add/change to transactions :

status: TransactionStatus
requestHandledBy: user id
requestHandledAt LocalDateTime
pendingHandledAt : LocalDateTime
make date Nullable (as we only want to enter date when the transaction is done)

TRASH area
TransactionsRequest :

id: Long	amount: BigDecimal	accountId: Long	status: TransactionStatus	title: String	description: String?	createdAt: LocalDate	upcomingId: Long?	deadline: LocalDateTime?

Created/edited/deleted by roots in any context
Created/edited/edeleted by user with enough perms on a sub-account when linked to a project (and within the project's funds limit)
Can be validated by roots, which blocks edition to this request and creates an Upcoming and store its Id
Can be refused by roots, which blocks edition
future idea : when rejected, unlocks a button allowing user with enough perms on a sub-account to create a new request with the same data (to win some time to avoid writing data from scratch)
Files can be linked to it
future idea : add ndf which will automatically create and fill a transaction request and its justificatives?

TransactionUpcoming :

id: Long	amount: BigDecimal	accountId: Long	status: TransactionStatus	title: String	description: String?	createdAt: LocalDate	transactionId: Long?

Created/edited (not deleted?) by roots in any context
Can be validated by roots, which blocks edition to this upcoming and creates a Transaction and store its Id
When validated, asks for a date sooner or equal to today (date at which the transaction was done)
!!!! Doesnt necessarily have a date associated with it (as EPITA payments can be fully random)
Can be cancelled by roots, simply blocking edition

# NOT FINISHED at all maybe dont bother with multiple object, just keep one transaction and add multiple columns to have the current status, know if there is a need for 'intermediate' objects ? Instead of discussing then manually adding transactions, request transactions, that must be reviewed then accepted or rejected. - To avoid having transations that could be request or 'real' transactions, create a new TransactionRequest model. - With the same objective, remove pending transactions and create a TransactionUpcoming model The workflow should look like : Request -> (approved or refused) -> TransactionUpcoming -> (after buying / receiving the money) -> Transaction The accountant/roots will be able to create request, upcoming and transactions, whether it is linked to a project or not. Meanwhile, clubs/members will be limited to requests creation, which must be linked to a project. Roots will be able to generate estimates (devis) from TransactionRequest (when they arent refused), and invoices (factures) from TransactionUpcoming (anytime? or only when not validated?) ----- Reduce transaction types to: - EXPENSE - INCOME - FUNDING (or maybe remove it ???? idk) Create a new filed for transaction with enum TransactionStatus : - Requested (color for front: light blue) - Refused (light red) - Upcoming (blue) - Cancelled (red) - Done (green) col to add/change to transactions : - status: TransactionStatus - requestHandledBy: user id - requestHandledAt LocalDateTime - pendingHandledAt : LocalDateTime - make date Nullable (as we only want to enter date when the transaction is done) ----- TRASH area TransactionsRequest : | id: Long | amount: BigDecimal | accountId: Long | status: TransactionStatus | title: String | description: String? | createdAt: LocalDate | upcomingId: Long? | deadline: LocalDateTime? | |---------|---------|---------|---------|---------|---------|---------|---------|---------| - [ ] Created/edited/deleted by roots in any context - [ ] Created/edited/edeleted by user with enough perms on a sub-account when linked to a project (and within the project's funds limit) - [ ] Can be validated by roots, which blocks edition to this request and creates an Upcoming and store its Id - [ ] Can be refused by roots, which blocks edition future idea : when rejected, unlocks a button allowing user with enough perms on a sub-account to create a new request with the same data (to win some time to avoid writing data from scratch) - [ ] Files can be linked to it future idea : add ndf which will automatically create and fill a transaction request and its justificatives? TransactionUpcoming : | id: Long | amount: BigDecimal | accountId: Long | status: TransactionStatus | title: String | description: String? | createdAt: LocalDate | transactionId: Long? | |---------|---------|---------|---------|---------|---------|---------|---------| - [ ] Created/edited (not deleted?) by roots in any context - [ ] Can be validated by roots, which blocks edition to this upcoming and creates a Transaction and store its Id - [ ] When validated, asks for a date sooner or equal to today (date at which the transaction was done) - !!!! Doesnt necessarily have a date associated with it (as EPITA payments can be fully random) - [ ] Can be cancelled by roots, simply blocking edition