Implement retrieval of current users, all projects and all issues of a particular project

[thiblahute]

No description provided.

[ianepperson]

Thank you for the pull request. Unfortunately, this came in at the tail end of a major refactor which included most of these features. I tacked on getting the currently logged in user information, but with the radical changes to the library, much of this is redundant (the library now grabs any fields that Redmine provides and each field doesn't have to be discretely coded) and not really possible to merge. getProject(id) became projects.get[id], there's a users.get[id], etc.

I know you've done some work to freshen up that old library. Are the new changes too radical to try out this new version?

[thiblahute]

Great to see you are currently working on that, and I rather prefer that you actually refactored the whole thing as it was well needed :)

My major concern is: Do you concider the API as stable already or not?

[ianepperson]

My major concern is: Do you concider the API as stable already or not?

If you had asked me when I first wrote this years ago, I would have said yes. With the rewrite, I was focusing first on stabilizing the API and setting the pattern for any future changes. I would love a review of the implementation and any critique of the API, but I do consider it complete - it has all the changes that I envisioned. Barring any major issues or boneheaded decisions on my part, everything else should be an addition.

I do need to scrub through it and make terms consistent, but that's just in comments and not exposed (database fields, object parameters, server actions and object methods). It would be nice if the item managers ( .users, .projects, .issues ) were visible on the class and available to the built-in help system, but the Redmine server object should not have those managers available if the version of Redmine doesn't support it, and those managers need a reference back to their parent object in order to function - so it seems like they need to be generated after object creation.

I really like that any returned object's cross references are full objects themselves. ( issue.project is the same project object as server.project[ issues_project_id ], and issue.project.parent is yet another full project object.) However, I wonder if this will trip people up since many of those returned items will have partial information since that's what the one query provides. I don't see a better way without more REST queries which would slow down a user script, often for no purpose. I added item.refresh() as a quick way to (try) and update the item's data (which will not work if Redmine doesn't provide individual access for that item type - like issue status fields.)

I'm not in love with the custom_fields representation, but I think it will work well enough - though perhaps a item subscript shortcut could be added. (Instead of item.custom_fields['my field'] maybe use item['my field'] to better integrate those custom_fields. Thinking more about it, I like that much more than the current implementation where the custom fields are grouped as an object - they still will be, but could also be accessed in this new manner.