So, the two endpoints I am using are almost identical, the only difference being the seed used in the creation of PDA for each of the accounts.
I will start with the abstract of my program:
First of all, the main account struct:
#[derive(Accounts)]
pub struct Initialize<'info> {
#[account(init,payer=user,space=8+8+2)]
pub my_state: Account<'info,MyState>,
....
....
MyState struct:
#[account]
pub struct MyState {
pub option: SelectOptions,
....
SelectOptions is an enum with options - Single and Multiple.
Now comes the two endpoints:
pub fn single_select(ctx: Context<SingleSelect>) -> Result<()> {
let my_state = &mut ctx.accounts.my_state;
require!(my_state.option == SelectOptions::Single,SelectError::NotCorrectSelection);
.....
Ok(())
}
pub fn multiple_select(ctx: Context<MultipleSelect>) -> Result<()> {
let my_state = &mut ctx.accounts.my_state;
require!(my_state.option == SelectOptions::Multiple,SelectError::NotCorrectSelection);
.....
Ok(())
}
The idea is to let user select a single item if Single option is saved in my_state and multiple items if Multiple option is saved. However, the user can only select each time single time. So, in order to avoid letting user select the item again, I am trying to create PDA account in the following way:
For single_select - The seed is user's public key to avoid user calling the endpoint second time.
For multiple_select - The seed is user's public key and item's id. Hence, user can call the endpoint more than once but he can't select the same item if it is already selected.
The code of account validation and program logic is exactly same for both the endpoints except PDA's seed. So, my question is - is it possible to select conditional seed based on whether Single or Multiple enum option is saved in the my_state account so I can avoid repeating the whole chunk of code twice and run the whole logic in a single endpoint?
= { }
, I've done something similar before with a conditionalspace
calculation. However I don't think that have a conditional seeds check is a good idea security wise. It adds to complexity and possible confusion