Summary: | Creating new patron attribute types should start with type choice | ||
---|---|---|---|
Product: | Koha | Reporter: | Pedro Amorim <pedro.amorim> |
Component: | Patrons | Assignee: | Pedro Amorim <pedro.amorim> |
Status: | In Discussion --- | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | gmcharlt, jonathan.druart, julian.maurice, kyle.m.hall, martin.renvoize, nick, oleonard |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36761 | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Attachments: |
Bug 36751: PoC
UI demo screenshot Bug 36751: PoC |
Description
Pedro Amorim
2024-05-02 11:04:24 UTC
Created attachment 166061 [details] [review] Bug 36751: PoC This is a PoC only. More work should be done here. Imo, ideally, we'd have a mapping where each 'model' would define what it supports ('repeateable', 'searchable', 'unique identifier', etc). But first would like to know what others think of this. Is this is a good idea? Should we invest more time here. Test plan, k-t-d: Visit patron attribute types at: http://localhost:8081/cgi-bin/koha/admin/patron-attr-types.pl Click "New patron attribute type" Notice you are now presented with choices in regards to the model of the attribute type: "Text", "Date" or "Authorized value category Notice if you pick "Date", you're unable to pick an authorized value category Notice if you pick "Authorised value category", you're unable to pick if its a date or not Created attachment 166062 [details]
UI demo screenshot
Yes, good idea, but I would put everything on the same view. The buttons on top of the form maybe? (In reply to Jonathan Druart from comment #3) > Yes, good idea, but I would put everything on the same view. The buttons on > top of the form maybe? Interesting suggestion, my idea was to do exactly the opposite of this, i.e. show the user the least possible UI elements at a time, to 'ease in' creating a new custom field, and show only the UI applicable elements once the type/model choice was done. If we show everything on the same view, we'd then need to hide unapplicable UI elements depending on the selected type through JavaScript (?) which is exactly what I'd like to avoid doing, e.g. if the user picks "Date", then the "Authorized value" input would be hidden by JS, and vice-versa. This is what is happening currently, but disabling/enabling UI elements instead of hiding, through JS. Which, again, is exactly what I'm trying to improve here. I agree with Pedro, the current form disabling some optoins as you enable others is unclear. I also agree with Joubu - the full intermediate page seems a bit too far. I think if you made the 'New patron attribute type' a split button - so you had a dropdown and could initially select the type before going to the form it would let you skip the extra page, but could also direct you there if you clicked the main button. Does that make sense? I like the idea of the split button approach :) Created attachment 166457 [details] [review] Bug 36751: PoC New PoC removing the intermediary screen and adding dropdown choices instead. This also now adds the 'model' column in the UI table. I would prefer to go deeper and update the database schema but I feel that might be too much for now. Test plan, remains the same but dropdown choices instead of new UI screen: Visit patron attribute types at: http://localhost:8081/cgi-bin/koha/admin/patron-attr-types.pl Click "New patron attribute type" Notice you are now presented with choices in regards to the model of the attribute type: "Text", "Date" or "Authorized value category Notice if you pick "Date", you're unable to pick an authorized value category Notice if you pick "Authorised value category", you're unable to pick if its a date or not |