This issue is for development and collaboration on a 7.x branch of the redmine module. As per the activity on the 6.x branch, the 7.x branch should aim to use Redmine's new REST API (see #942050).
Here are some initial thoughts to get the ball rolling:
- Abstract out code for communicating with Remine REST API. http://drupal.org/project/twitter is a great example to follow for modeling a Drupal module which interfaces with a REST API. Also this code could be reused for the 6.x and 7.x versions.
- Caching mechanism. Store Redmine objects in the database to avoid constantly calling the REST API
- Maintain a link between Drupal user accounts and Redmine user accounts. 1-1, 1-n or n-n?
- Build custom views query backend to expose the REST API to views, allowing for user configurable lists of Redmine objects.
- First version of the module could aim to be strictly pull, pulling data for display from Redmine. Later versions could add push, where the module would facilitate things like creating issues, users, time entries and projects.
Here are some resources for reference, including a virtual machine stack from bitnami that I found to quickly and easily get a Redmine environment up and running.
http://www.redmine.org/projects/redmine/wiki/Rest_api
http://demo.redmine.org/
http://bitnami.org/stack/redmine
Love to get feedback on this. Also is there any work being done currently on the 6.x branch that could be used here as well? Checking CVS HEAD didn't show anything new. By the way I'm relatively new to creating issues and such, so please forgive me if I've veered off the norm.
Thanks,
Matt
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | modules.zip | 43.83 KB | Jaras |
Comments
Comment #1
m4oliveiDidn't format that issue link properly: #942050: Use Redmine's REST API.
Comment #2
Bevan commentedI never thought of Views integration—that is a great idea.
This ticket is fine. The next step is patches.
I would prefer to see #942050: Use Redmine's REST API committed before branching to D7.
Comment #3
Jaras commentedHi,
I've just ported redmine api and rest api query modules, created by Bevan to D7.
Any comments/suggestions are welcome, and please be nice it's my first contrib to drupal ;-)
Jarek
Comment #4
Bevan commentedThanks Jaras. Great stuff!
Please contribute these as Git-patches; http://drupal.org/node/707484
Please contribute one patch here for Redmine API and another patch in the REST API Query queue.
Are you interested in becoming a co-maintainer to maintain the D7 branches?
Comment #5
mattp52 commentedSubscribing.
Comment #6
Bevan commentedREST API Query now has a 7.x-1.x dev branch which is working with my brief testing, but will certainly be missing things and buggy. I have not tested it with Redmine API module or the code contributed here. Though many of the changes in both 6.x and 7.x-1.x were inspired by Jaras' code in comment #3.
That frees up this issue focus more on Redmine API's port to Drupal 7 and any bugs found in REST API Query can be fixed independently in it's own issue queue.
Comment #7
molave commentedSubscribing
Comment #8
modoq commentedsubscribing
Comment #9
svipsa commentedsubscribing
Comment #10
wesnick commentedHi,
I am starting to implement this API for use with Drupal 7. I will be using the awesome wsclient module as the basic framework since this module includes a nice way to incorporate remote REST calls into a Rules workflow.
I will be working on this in a sandbox, but was interested to see if others would want to collaborate.
Comment #11
Bevan commentedRedmine API depends on the REST API Query API module, which I think provides similar APIs to WSClient (though I have not looked at it in detail). Are you certain it makes sense to depend on both?
Either way, you will have a hard time convincing me that Redmine API module should not use REST API Query API module, since I wrote the latter specifically for Redmine API module (And Toggl.com API module). :)
Please try convincing me though if you think WSClient is better or more suited.
Comment #12
wesnick commentedHi @Bevan,
I'm sorry, I didn't mean to presume to rearchitect your solution. In actuality, the WSClient module does not really provide the actual interface to query the REST service, rather, it depends on the HTTP Client Module for REST services and the PHP SOAP extension for SOAP services. The utility of the WSClient module is that it integrates with Rules so you can invoke your web services and populate other data structures based on other conditions.
Currently, I am trying to make a sort of Views plugin for this module so that services can be queries using a Views filters or arguments. See #1215570: Views Integration for 'Web service client' module. My only real interest in implementing the Redmine API is that is a rather simple service that I actually have access to test my implementation of this with. I thought I might be able to use this code for a 7.x patch, but if you have other plans, then I have not problem with that.
Comment #13
Bevan commentedI am still interested to understand what part WSClient would play in this, if any.
Comment #14
sheldon rampton commentedBTW, I've started writing a Drupal 7 redmine integration module using the PHP ActiveResource library:
http://www.redmine.org/projects/redmine/wiki/Rest_api_with_php
The ActiveResource library uses XML rather than JSON as the data transport format and also eliminates the need for a dependency on the Rest API Query module. It also provides support with very minimal coding for some things that the current Redmine API module for Drupal doesn't support, such as getting and creating Remine groups. It would need some coding beyond what I've already done to support the full Redmine API. (For example, support for adding and updating project memberships would require some additional coding.) I'm wondering if I should offer this as a D6->D7 upgrade patch to the existing Redmine API module for Drupal, or if I should create my own separate Redmine integration module.
Comment #15
Bevan commentedPatch. :) Such a change would warrant a new major version number; So the branch would be 7.x-3.x.
Comment #16
sheldon rampton commentedYeah, it's a major change. My version also eliminates the redmine_user_access_keys module, which I think is unnecessary in Drupal 7 where user accounts are fieldable. Moreover, the ActiveResource authenticates using the Redmine username and password rather than the Redmine user API key, so the redmine_user_access_keys module doesn't really work anyway. It's also pretty easy to set things up so the integration module can support queries of multiple Redmine instances. This could be useful in porting content between different Redmine instances or in some other use cases that I can imagine.
I'm happy to submit this as a patch to the existing module as you've suggested, but I just wanted to forewarn you that my approach is a very from the existing module.
Comment #17
Bevan commentedI understand! That is why it would be in a new major version number. :)
If you prefer I can give you commit access and you commit it to the new branch.
Comment #18
sheldon rampton commentedHi Bevan. I've got a version of the D7 module working. It's still missing some pieces, and there is some redundant and unnecessary code that I'd like to clean up before offering it as a patch, but I put the code into a GitHub repository for the moment so you can look it over if you'd like. I'd appreciate your evaluation of the approach I'm taking. You can get a pretty good idea how it all works by reading the included README file.
I'm also interested in developing a Redmine Views module, but I haven't written any Views plugins or handlers previously, and it looks like you have. I wonder therefore if you could give me some pointers to help me along. (In particular, I think I'll need help developing a Views query plugin, which doesn't seeem to be very well documented. It looks like you've written one already for the Toggl module.)
Here's the GitHub repo where I've placed my version of Redmine 7.x-3.x for the time being:
https://github.com/nuams/redmine-drupal
Comment #19
Bevan commentedSheldon;
Dave Reid has also written a D7 version that does not depend on rest_api_query. Unfortunately he didn't post about it in the issue queue and I only just noticed it. If we had known about it earlier you could have merged efforts.
Please review each other's work and decide how to best collaborate or merge efforts.
http://drupalcode.org/project/redmine.git/tree/refs/heads/7.x-rewrite
Comment #20
sheldon rampton commentedActually, after reviewing Dave Reid's code, I think our approaches are broadly compatible and complement each other rather than compete. We're both using the PHP ActiveResource module as our starting point, so I think that part of what he has done can be combined with mine with only minimal work to rename a few subclasses. Other than that, the new functionality he has created is mostly new and different (but useful in its own right) from the functionality that I've created. For example, he has added Token support and exportables, neither of which are in my version.
Can you give me co-maintainer status on this module so I can merge my work into Dave's branch? I'll be careful to communicate with him so we avoid working at cross purposes.
Comment #21
sheldon rampton commentedI just updated my GitHub repo with a version of the Redmine 7.0 module that combines all of my code with all of Dave Reid's. Actually, it was incredibly easy to combine them. I've got it running on a test instance of Drupal on my laptop.
https://github.com/nuams/redmine-drupal
The combined version should include all of Dave's functionality with all of mine.
Comment #22
Bevan commentedFantastic! I would prefer it if Dave Reid made you a maintainer; I believe he has access. If not he can let me know here and I will add you. Please PM me if I don't check back promptly so as not to delay your collaboration. :)
Comment #23
sheldon rampton commentedGreat, I'll work this out with Dave and see if we can come to agreement.
Comment #24
anyulled commentedcould you please tell the status for this project? I'm trying to install this module from the github source but it throws several errors. Would you mind adding an official version and placing a tar.gz file for Drupal 7, please?
Comment #25
sheldon rampton commentedannyulled: I wouldn't recommend trying to use the module at present. It's still in a very alpha state and will almost certainly undergo major changes before it is ready for production use. Dave Reid and I have both done some work on it and have discussed a plan for combining our efforts, but that will entail some significant changes from the version that is currently on my GitHub repo.
Comment #26
anyulled commentedJaras:
Very good! I managed to install the REST API Query, but can't install Redmine API User Access Keys because it depends on User_access_keys, but it isn't available for D7. How did you manage to solve this?
Thank you very much
Comment #27
scottshipman commentedBevan, Dave or Sheldon,
Is there a status on this module? I am / was about to undertake a port to D7 of the Redmine API, but it sounds like you have done so much already. Is there anything I can contribute or assist with?
My long-term goal is to do an organic groups and redmine integration = so that a redmine project can map to a group, with all role and user relationships in tact from both directions. For instance, new / existing members of a group can participate in any project associated with that group, including svn / git integration.
I also hope to do a kanban front-end to the task management data in redmine, giving it an AGILE feel.
-scott
Comment #28
sheldon rampton commentedScott,
My version and Dave's version do somewhat different things. After discussing this with Dave, I've realized that some further work would be necessary to get the two parts to work together harmoniously. I've also decided that my approach is rather inelegant, and unfortunately I don't have any time in the near future to work on this and pull it all together.
Having said that, you can check out my Github repository which combines Dave's code and mine into a single module:
https://github.com/NewAmsterdamIdeas/redmine-drupal
Just bear in mind that the coding approach you'll find there differs significantly from the approach that either Dave or I are contemplating for future development if/when we ever get back to working on this. If you find it helpful, feel free to use it as you see fit, but just bear in mind that it does not reflect my current thinking about the direction that should be pursued in building this module. For one thing, my code currently uses the PHP ActiveResource library to consume Redmine's REST API, and I think some other REST client would be better, especially now that Guzzle is being added to Drupal core as discussed here: http://drupal.org/node/1447736
Comment #29
greg.harveyHi everyone,
So I had looked at releases for this project and assumed it abandoned, but seems there are a few D7 ports in the offing, though this seems to have stalled. I *didn't* port. Because I thought the project abandoned and didn't think to check the issue queue, I made this:
https://drupal.org/project/redmine_rest_api
I'm using it right now in production for a bunch of support dashboards - it's only a dev snapshot, because I want it to run for a few months before I call it a point release, but it's fairly robust, probably because it's very simple. I haven't yet had chance to review Dave and Sheldon's work - had I found this it would surely have saved me some work, but oh well! - so I don't know if there's anything useful in my module which might roll into these efforts.
I also don't know where things stand between the two versions - the last post here implies continuing with Dave's re-write is the best way forward, so I'm happy to review that and try to see if I can get my Redmine Issues module to work with it as a learning exercise. Without looking, I'm guessing the main thing my module might bring to the party is the user API key look-up facility, which circumvents httpauth for older versions of Redmine (albeit requiring a very minor patch) - I'm not sure how this module handles masquerading as other users right now, but I presume it uses the http headers approach?
Anyway, I guess my homework is to see what's involved to make Redmine Issues work with Dave's D7 port. Any advance on that?
Comment #30
greg.harveyGah, OK so the 7.x-rewrite branch referenced in #19 as containing Dave's work doesn't actually exist any more? Which reverts me to the 'this is probably abandoned' position. Please do let me know if there's anything officially relating to this project for D7 I can try to use. =)
Comment #31
sheldon rampton commented@greg.harvey: My github repository actually combines all of Dave Reid's with all of mine, and it's still available online:
https://github.com/NewAmsterdamIdeas/redmine-drupal
Dave took down his 7.x branch because of a security issue that I don't want to describe in further detail here, but if you want to get just his version without my stuff I'm sure he or I can get it for you. You're welcome to do what you want with the code in its current state, but I don't think either Dave or I have time to put much effort into it right now, and our respective approaches are somewhat different. Also, neither Dave's approach nor mine is consistent with the approach to write REST API client libraries that is planned to become the standard in Drupal 8, as discussed here:
https://drupal.org/node/1447736
I'd be happy to discuss this further with you. I can tell you enough about what's working and what isn't that you can at least decide whether it's useful for your needs.
Comment #32
Bevan commentedGreg & Sheldon; Might it be useful to either mirror Sheldon's GitHub code on Drupal.org or update the project page to link to it?
Comment #33
sheldon rampton commented@Bevan, either is fine with me. Currently I am not a committer on this project, so if you want to add my Github repo someone other than myself would need to do it.
In reading Greg's comments, it appears that he has created his own separate Redmine module, so I don't know if he actually wants our code. Regardless, he's welcome to do whatever he wants with my code.
Comment #34
greg.harveyHi guys,
I want to do what's best for Drupal, didn't intend to duplicate existing work but didn't find any existing work so I wrote a module. Mine is very simple, doesn't have any extra integrations because I just don't need them. All I need is a dumb API call.
BUT if there is serious intent to continue this project for Drupal 7 then I'd rather refactor my issues module to use this and mothball my module. I think it's better if there's a known 7.x-2.x-dev branch we can work from - there being no D7 release was why I passed over this. (Or perhaps 7.x-3.x-dev? How different is it?) Any reason why we can't just put Sheldon's work on d.o like Bevan suggested?
Comment #35
Bevan commentedI made you a maintainer Sheldon. Feel free to maintain your code here or just link to other project's repositories—as you see fit.
Comment #36
rogical commentedCan't wait to see D7 branch
Comment #37
bradjones1FYI; trying to breathe life back into this. For convenience I have forked the project reference above on GitHub and have done a good bit of cleanup on it today; I'll be contacting Dave Reid about a 7.x dev branch so we can at least get some traction on drupal.org.
https://github.com/bradjones1/redmine-drupal
Comment #38
avpadernoI am closing this issue, as it has been created for a release that is now not supported.