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

Fields marked @readonly only being readonly in frontend #27048

Open
1 task done
OmarHawk opened this issue Aug 23, 2024 · 4 comments
Open
1 task done

Fields marked @readonly only being readonly in frontend #27048

OmarHawk opened this issue Aug 23, 2024 · 4 comments

Comments

@OmarHawk
Copy link
Contributor

OmarHawk commented Aug 23, 2024

Overview of the feature request

We are using the @readonly annotation on a few fields. These fields are becoming frontend side read-only, but on backend / database side, there is nothing preventing an (accidental) update of the fields.

So, if some other process actually updates the data in the fields and the user has already loaded the data in the readonly input fields on frontend (Angular in our case), the user would submit the old value and the backend is happily taking the old value as the new value and writing it back into the database.

On JPA level (we are using mysql), it would be kind of easy to prevent this without having to hassle around with errors or something else. Just putting updateable = false and insertable = false will silently ignore this field for any update / insert command.

@Column(name = "mycolname", updatable = false, insertable = false)

Since it is anyway something that could only be achieved by accident or manipulation by a user, I think, this would be the easiest and best solution, as no explicit error needs to be handled / shown to the user.

Motivation for or Use Case

Prevent accidental / manipulative overwrite of data in readonly fields

Related issues or PR

I can prepare a PR if you want.

  • Checking this box is mandatory (this is just to show you read everything)
@mshima
Copy link
Member

mshima commented Aug 23, 2024

Please go ahead.

@OmarHawk
Copy link
Contributor Author

OmarHawk commented Aug 23, 2024

FYI - the generator automatically sets id fields as readonly. Here, we should not set these annotation parameters of course. :-)

Additionally, we should probably put an additional test in place for such fields.

@mshima
Copy link
Member

mshima commented Aug 23, 2024

I've remembered now, readonly was added to implement id fields just like any other field instead of an exclusive section for ids in ejs templates.
So a autoGenerated id is a readonly in the frontend, a non autoGenerated id is a non-updatable field in the frontend.
It wasn't a full implementation.

OmarHawk added a commit to OmarHawk/generator-jhipster that referenced this issue Aug 26, 2024
to more easily extend jakarta persistence configuration in Column

jhipster#27048
OmarHawk added a commit to OmarHawk/generator-jhipster that referenced this issue Aug 26, 2024
to more easily extend jakarta persistence configuration in Column

jhipster#27048
OmarHawk added a commit to OmarHawk/generator-jhipster that referenced this issue Aug 27, 2024
to more easily extend jakarta persistence configuration in Column

jhipster#27048
OmarHawk added a commit to OmarHawk/generator-jhipster that referenced this issue Aug 27, 2024
@Tcharl
Copy link
Contributor

Tcharl commented Aug 28, 2024

Is it also worth generating setters? Would contribute in a way to #26007 if setters are removed

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

No branches or pull requests

3 participants