Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to customize pentesters object #226

Open
danymat opened this issue Mar 13, 2024 · 2 comments
Open

Ability to customize pentesters object #226

danymat opened this issue Mar 13, 2024 · 2 comments

Comments

@danymat
Copy link

danymat commented Mar 13, 2024

Hello,

It's again me.
I'm trying to get a hands on a new design, and I need to create a "Team" List, comprising of Name and Internal identifier (such as PENTESTER_0001)

As of right now, we will use a custom list, comprising of objects that have name and internal_id parameters.
However, I was thinking on having the ability of customizing the pentesters object with custom string parameters.

Do you think it would be feasible ? Or does this functionality already exist ?

@MWedl
Copy link
Contributor

MWedl commented Mar 13, 2024

Hi,
currently it is not possible to define internal_id fields for user objects in the pentesters list. I think adding custom properties to user objects is a great idea to enhance customizability which could be useful in many scenarios.

Are internal_ids global per a user (i.e. the same for every project) or are they different for each project?

A big challenge is how to define the schema for custom global user properties (similar to report/findings fields in designs). I think this will get quite complicated to implement, because we would need to handle schema conflicts on export/import on other instances. Therefore I suggest to keep the user properties a simple object of key-value pairs where values are always strings.

@danymat
Copy link
Author

danymat commented Mar 15, 2024

Are internal_ids global per a user (i.e. the same for every project) or are they different for each project?

I think we should start simple, aka global for all projects.
At the moment, we use the title_before and title_after to circumvent the limitation (as defined https://docs.sysreptor.com/designer/field-types/#user)

Therefore I suggest to keep the user properties a simple object of key-value pairs where values are always strings.

This is a very good idea, and should be enough for usage

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants