avo
avo copied to clipboard
`:has_one` field doesn't respect disabled
Describe the bug
When using :has_one association field, it doesn't respect disabled: true when the association is already present (you can remove it). When there is no association, no create association button is visible.
Steps to Reproduce
Steps to reproduce the behavior:
- Add
:has_oneassociation withdisabled: truefield :user, as: :has_one, disabled: true - Go to the record and try to remove the association
Expected behavior & Actual behavior
It should not allow to remove/delete/edit the association.
Models and resource files
System configuration
Avo version: 3.5.3
Rails version: 6.1.7.7
Ruby version: 3.1.4
License type:
- [x] Community
- [ ] Pro
- [ ] Advanced
Are you using Avo monkey patches, overriding views or view components?
- [ ] Yes. If so, please post code samples.
- [x] No
Screenshots or screen recordings
Additional context
Impact
- [ ] High impact (It makes my app un-usable.)
- [x] Medium impact (I'm annoyed, but I'll live.)
- [ ] Low impact (It's really a tiny thing that I could live with.)
Urgency
- [ ] High urgency (I can't continue development without it.)
- [ ] Medium urgency (I found a workaround, but I'd love to have it fixed.)
- [x] Low urgency (It can wait. I just wanted you to know about it.)
:has_many behaves probably the same.
@krystof-k disabled and readonly are form input arguments. The mentioned association fields are not inputs on a form so that options do not affect them. If you want to have some granular control over the permitted actions on that fields the best approach is to use authorization https://docs.avohq.io/3.0/authorization.html#associations
OK, but it does affect the buttons when there is no association, so I'm a little confused.
disabled: false:
disabled: true:
I think it would be reasonable to disabled work for all fields correctly.
I know it is possible to use the authorization and I get the @adrianthedev's argument in #2552, but I think this is a little confusing and I understand the authorization as something which controls who can do what, whereas this is related to what is possible where.
Good point on the disabled option, should be coherent and disable all buttons or disable none.
I understand the authorization as something which controls who can do what, whereas this is related to what is possible where.
Understand it but I think that both can be achieved in one single point, on a policy file... Having multiple places to restrict actions is confusing. You can use authorization to control by role (who can do what) or just true / false (what is possible where)
Yeah, sure it can, that is your design decision. In that case, what about raising an error when disabled: true is used for an association field? However for :has_one, it works fine with disabling the select box, so I'm not sure, complicated…
This issue has been marked as stale because there was no activity for the past 15 days.
I understand the confusion with disabled, but the truth is that the has_one has more than just one state. A user can attach/detach/create records on it, so that's why we chose to control that using policies as we control the rest of the associations.
Yeah, sure it can, that is your design decision. In that case, what about raising an error when
disabled: trueis used for an association field? However for:has_one, it works fine with disabling the select box, so I'm not sure, complicated…
We'll take a PR for that.
We decided to make it coherent by removing the disabled option on associations fields. I.E disabled: true will stop working even when there is no attached record. Associations controls should be entirely controlled by policies and custom controls. Thanks for reporting this and for all the details @krystof-k
field :admin, as: :has_one
field :team_members, as: :has_many, through: :memberships
field :admin, as: :has_one, disabled: true
field :team_members, as: :has_many, through: :memberships, disabled: true
Approach
- Remove the
disabledandread_onlyoptions from association fields, ensuring they no longer have any functional impact. - Document this as a breaking change, noting that this decision was made to maintain consistency across association field types. The breaking change documentation should advise users to search for instances of the
disabled: trueoption and ensure that any relevant use cases are handled by appropriate policy settings.
Docs about breaking change that disabled was removed and only policies are applied on associations controls.