Deprecate the patron module

Attached is my first attempt at this. My local installation is functioning as expected with it. Not really included is library.actions.inc, it has not been fully reviewed regarding send_email and renew. Also, I was unsure how to properly let the conditions in the install file fail for update_6201.

To accommodate being able to specify fields other than the user name to search for during transactions I added support for the profile and content_profile module. You can now select textfield fields from those modules (when enabled) under admin/settings/library and they will be searched and shown by the autocomplete function in addition to the user name.

The attached patch also includes numerous small suggestions from the coder module as well as a rules event on library actions. I tried splitting the patches for this up but ran into several conflicts. Please let me know if that's a problem. (Taking out the rules events should be trivial, the coding style issues, not quite, after all the other changes.)

A shortened version is attached, in a few instances a coder module suggestion was close to a modified region and I left them in, I hope those aren't too distracting.

Forgot to hit attach...

Please remember you can make a 6.x-.1.0 release with patrons and finish the non-patrons support in a new 6.x-2.0 branch.

Well, this is obviously you decision but remember that you don't have to really support two different versions.

You can release the current version with patrons (and support it as far as it seems reasonable to you, maybe even taking the radical position of marking all 6.x-1.0 patron related bugs as "by design" or "won't fix") while developing the new patron-free version.

When you get to the point of releasing the new version you can deprecate the previous version. This way you won't have to support two versions at any time.

I'm mentioning (and insisting) on this topic just because I know of at least one module that doesn't use Library because of the lack of any proper release (phpMailer it is but I bet there are others) and I didn't suggest Library module for the Messaging module maintainers for the same reason.

It gets rather prohibitive for other module developers to adopt your module without a proper release they can relate to and I'm sure this is slowing Library's adoption which is a loss to all:
* Library maintainers that don't see their work adding as much value as it could to the community and
* other module developers and users that have to deal with the problems that Library module could already be solving had it a proper release.

But, again, the final decision is yours. I won't rant anymore.

Great module. I definitely like the transition from patron to drupal user. Do you have an idea when you might have this rolled into the next release? We have a nice testing environment for this module, but the use of the patron module does not work for our needs, but will be great when it allows for drupal users. :)

No problem. I wish I was a developer so I could help it out. I can definitely help with testing though. Looking forward to any future developments :)

Sorry about not responding earlier, I got a bit buried under my master's thesis. I have recently made good progress for an improved upgrade path which moves the patron fields into profile or content_profile fields.

My progress is attached, the profile module seems to work so far, the primary remaining issue I'm running into with this is that I have not yet found a good way of adding cck fields automatically to a content type.

Hi - appreciate the patch. It was EXACTLY the improvement I was looking for. Took a little while to configure though. Just being picky but I think the dependencies need to become:

dependencies[] = profile
dependencies[] = rules

Or at least I had to enable those modules to get the patch working.

Attached is the complete patch including a complete importing routine, which should work reasonably well with either profile or content_profile.

The only thing I didn't change yet is the 'search library patrons' permission. My motivation behind this was to make it possible to let a user (say, a part-time staffer) have a permission set that allows him or her to perform a transaction, but not necessarily access the profiles in their entirety. If you think this is ultimately a bad idea, feel free to change that line or let me know if there is a dimension to that issue which the module does not yet consider.

--

@Dartoxian, I think you might have used the first patch, not the later one which included a call to the rules module (rules is postponed for now). The profile module should not have been necessary, as far is I remember, though you'd probably want to have either content_profile or profile turned on to search for users to check things out for by criteria other than user name. So, a strict dependency in that case would be difficult.

Thanks, this module is really getting somewhere really interesting!
I would like to help to test it out without the patrons but I'm having a hard time installing the patch in #15...
Pardon me for asking but which version does it apply to?
Also, is it a normal patch we apply with "patch -p0 < ..."?
Thx for your time!

Changed permission to access user profiles, patch attached.

For the commenter above: I'm not too well versed in the details of the patch command but trying out "patch -p0 <" has not worked for me while "patch -p1 <" has worked fine.

Omitting -p1 is not possible since plain "patch <" does not parse subdirectories properly for some reason and thus the file in the includes directory would go into the root and the patron directory is not found.

For this module it seems like you get a strange response either way.

1st try...............

patch -p0 < 814986-complete_4.patch

patching file b/includes/library.cck_fields.inc
can't find file to patch at input line 299
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/library.admin.inc b/library.admin.inc
|index ceab47f..b3d7095 100644
|--- a/library.admin.inc
|+++ b/library.admin.inc
--------------------------
File to patch:
----------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------

2nd try .....................

patch -p1 < 814986-complete_4.patch
patching file includes/library.cck_fields.inc
patching file library.admin.inc
patching file library.info
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file library.info.rej
patching file library.install
patching file library.module
patching file library.pages.inc
patching file patron/patron.info
Reversed (or previously applied) patch detected! Assume -R? [n]

I can reproduce your bug with 6.x-1.x-dev. The patch applies cleanly with -p1 to library-HEAD from CVS. Just tried the patch again on a clean copy of both of them and HEAD worked, dev didn't.

SWEEEEEEEEETTTTTTTTTTT! This is cool!!!!! would you say that it is just as stable as the dev version that is listed on the main library module page? It worked just like I expected it to but I haven't tested it with any of our actions and triggers for email messages.--I assume there would be no issue.

@daengo As far as diff shows, CVS currently differs from dev only in terms of file headers, the packaging information in library.info and the latest patch from 319676. Apart from that it's the same.

Thanks for all your work in reviewing and moving this patch along jastraat!

I looked into the patron autocomplete for profile a bit more just now and have a partial solution to querying the profile_fields properly and avoiding duplicates. Did you have any preference in how the results would be outputted, e.g.: username ( Field1, Field2, ...) or something different?

I'm wondering if it's worth the effort to make the field order configurable in the admin interface.

The attached patron autocomplete patch works well for me, please indicate if you had other things in mind as well and I'll try to ammend it.

--
Edit: Just after uploading I noticed I still had users AS u instead of {users} u, sorry about that.

Just to clarify...if you already had "Associate Library Patrons with Drupal Users" enabled, there should be no issue with any of these recent patches, however, for jaastrat's most recent patch you need to have profile enabled? Can the profile module still be disabled and these newest patches still work? I ask because I had a conflict with the webserver_auth module last time I enabled profile. So I was hoping that would be optional. I like the way this is moving the last few weeks and really hope for a non-developer version for 6.x sometime in the near future. DOes that look likely?

Thank you for all your work on that branch, I plan to test it with a staging system extensively this weekend.

Nice work. Subscribing...