Prolong multiple (but not all) items at the same time
Closed this issue · 4 comments
In library systems where it is possible
maybe also with an option to automatically select all the items that expire soon
I'm interested in this feature. Currently prolong takes a String argument identifying the items to renew:
From here I see three options:
-
Change this to a list of strings
This requires all existing APIs to be changed - not a big deal but still a break in backward compatibility. -
Make a new function
prolongMultiplethat takes a list of strings as argument
Straightforward, but leads to some duplication of code. We have now three functions for renewals (prolong,prolongAll,prolongMultiple). -
Use the existing prolong function and pass it a single string with all the items to renew
The items are separated within the string by a suitable separator (e.g. newline). Still requires rework of all existing APIs but keeps the signature unchanged.
I'm not sure what is the best way to go, I personally tend to 2. What do you think?
To keep things relatively simple, I suggest adding a new menu item "Prolong due items/Fällige Medien verlängern" that renews all "orange" items, so the user can - by setting the notification warning period in the preferences to 0, 1, 3 or 7 days - control which items should be renewed by this function. Do you agree?
To keep things relatively simple, I suggest adding a new menu item "Prolong due items/Fällige Medien verlängern" that renews all "orange" items, so the user can - by setting the notification warning period in the preferences to 0, 1, 3 or 7 days - control which items should be renewed by this function. Do you agree?
Sounds good!
As for the API, I think either 1 or 2 is fine, I don't like 3.
What do we do with library systems that natively only have a web/api call to prolong one item? Disable the feature, implement a for loop in the api class or implement a for loop in the UI code?
I think we'll need to be able to disable the feature at least for some APIs. IIRC, there is an API (Adis?) in which the items do not have IDs, but are only referred to by offset. For example, we'd send a request that says "prolong 3rd item in account". Obviously, after the first item is prolonged, the order changes and therefore all identifiers do...
As for the API, I think either 1 or 2 is fine, I don't like 3.
OK, let's go for option 2 then. API providers can than decide if they want to handle single renewals as a special case of multiple or not.
What do we do with library systems that natively only have a web/api call to prolong one item? Disable the feature, implement a for loop in the api class or implement a for loop in the UI code?
I think we could do it the same way as with ProlongAll: use a flag SUPPORT_FLAG_ACCOUNT_PROLONG_MULTIPLE to indicate whether the API supports this feature and provide a stub implementation if not. API providers can then decide if they want to implement this feature using native methods of the underlying web api or simulate it using a loop.