Hi Paul, Thanks for your suggestion and a detailed use case Yes, that is what I to implement. In your example, Maria will tell Bob which option she wants to use when she checks out a book. In this case, this is a custom solution and I need to worry about it during the upgrade process. I don't want to go for custom solution if possible.
Best Regards, Chee On Tue, Jan 8, 2019 at 11:24 AM Paul Hoffman <p...@flo.org> wrote: > On Mon, Jan 07, 2019 at 06:34:54PM -0500, Chee Hong wrote: > > Thanks for your reply and explanation. I agree with you that it will be a > > maintenance nightmare for the upgrade. Personally, I think this is a nice > > to have feature. In order to realize my use case, I need to create 2 > patron > > accounts for users who need to have this special privilege. > > Unless I'm misunderstanding or have forgotten what you wrote in your > original post, what you're looking for is a way to enable an interaction > such as this... > > ------------------------------------------------------------------------ > Maria (a graduate student who also works as an adjunct faculty member) > brings a book to the circulation desk and asks to check it out. > > Bob (a circ staff member) scans Maria's barcode, or searches using her > name. > > Koha indicates that there are two options to choose from when performing > the checkout: > > (1) Check it out to Maria as a graduate student. > (2) Check it out to Maria as an adjunct faculty member. > > Bob selects the desired option. > > (Alternatively, Koha sees that #2 would result in a longer loan period > and selects that option automatically.) > ------------------------------------------------------------------------ > > Furthermore, you would prefer to do this without the added burden of > having two separate patron records (i.e., two different rows in the > "borrowers" table) in Koha. > > Am I understanding correctly? > > If so, it might be useful to think of this at a higher level of > abstraction. Here are my ideas... > > We keep the two separate records -- each must continue to have a unique > cardnumber, which may make this idea unusable -- but link them in some > way. > > Maria is a person with two roles at your institution. We create a new > "object" -- a Person -- and reference Maria (the Person) from each > patron record. > > In concrete terms, this might mean: > > ------------------------------------------------------------------------ > CREATE TABLE persons ( > personnumber INTEGER PRIMARY KEY, > preferred_borrowernumber INTEGER REFERENCES borrowers(borrowernumber); > ); > ALTER TABLE borrowers > ADD COLUMN personnumber INTEGER REFERENCES persons(personnumber); > ------------------------------------------------------------------------ > > Then (*handwave*) we add an interface for linking borrowers, another for > selecting the desired borrower from a list of linked borrowers, etc. > > It's just a thought... > > Paul. > > -- > Paul Hoffman <p...@flo.org> > Software Manager > Fenway Library Organization > 550 Huntington Ave. > Boston, MA 02115 > 617-989-5032 > _______________________________________________ > Koha mailing list http://koha-community.org > Koha@lists.katipo.co.nz > https://lists.katipo.co.nz/mailman/listinfo/koha > _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha