-
-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Comments
Please go ahead. |
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. |
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. |
to more easily extend jakarta persistence configuration in Column jhipster#27048
to more easily extend jakarta persistence configuration in Column jhipster#27048
to more easily extend jakarta persistence configuration in Column jhipster#27048
Is it also worth generating setters? Would contribute in a way to #26007 if setters are removed |
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
andinsertable = false
will silently ignore this field for any update / insert command.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.
The text was updated successfully, but these errors were encountered: