[WIP] Redmine improvements
This PR is for #390. I'm posting this now in case someone wants to carry on, I'm going to be mostly offline for the next few weeks. (If you do work on this please post here so we're not working to cross purposes!)
- Load comments as annotations
- Support for custom fields
- Pagination support for more than 100 records?
- Fix tests
Everything here is working for me, btw.
I rebased. I'm a little horrified that this new github feature encourages this kind of thing though. Anyone with commit access can anonymously screw with PR's and the modifications are unlikely to be detected if they're careful. In other words, you can no longer count on the submitter to have reviewed their own PR!
@ryneeverett this all works, but I could use help figuring out what to do with the tests. Also, is it best practice to map the Redmine due date directly to a TW due date? I'm not sure the other services do this.
Reactions in no particular order:
1. Do we know why redmine's time zones are different than other services? In the tests, the other services return a datetime with a `pytz.UTC` timezone while redmine returns a datetime with a `dateutil.tz.tz.tzutc()`. This may well be an inconsistency in the way I wrote the tests, but it is curious.
2. The UDA `ASSIGNED_TO` appears to be equivalent to gitlab's `ASSIGNEE` and bz's `ASSIGNED`. Would it make sense to standardize? I'd be inclined towards `ASSIGNEE`.
3. The following UDA's appear to be completely unique across services:
I haven't developed an opinion on their merits, but this may be worth considering and soliciting feedback on.
@ryneeverett thank you for fixing the tests!
> Do we know why redmine's time zones are different than other services? In the tests, the other services return a datetime with a pytz.UTC timezone while redmine returns a datetime with a dateutil.tz.tz.tzutc(). This may well be an inconsistency in the way I wrote the tests, but it is curious.
I'm not sure about this, sorry. I do know that what's in `redmine.py` in this PR works for keeping the dates consistent after running `bugwarrior-pull`, when I first started working on this PR, Taskwarrior thought that the date field was changing across each sync and would update each task on every pull.
> The UDA ASSIGNED_TO appears to be equivalent to gitlab's ASSIGNEE and bz's ASSIGNED. Would it make sense to standardize? I'd be inclined towards ASSIGNEE.
Up to you. `assigned_to` and `assigned` are how these fields are defined in Redmine, so IMO it makes sense to keep the same format for this service, but I don't have a strong feeling about it one way or the other.
> The following UDA's appear to be completely unique across services
Same as above, these are core fields provided by Redmine for issues. I use all of them in my Taskwarrior reports, so I'd like to keep them :)
A related point, in Redmine one can have custom fields. I'm not sure if it's within scope to allow a user to define custom fields to pull from or how we could achieve these in `.bugwarriorrc`. But if there is a solution for custom fields, then I could use that for ESTIMATED_HOURS and SPENT_HOURS, etc.
> Also, is it best practice to map the Redmine due date directly to a TW due date?
No. See https://github.com/ralphbean/bugwarrior/issues/385.
Ah, the timezones are probably different because they're retrieved from `task calc`. I don't think that's a problem in itself though.
thanks very much for your help @ryneeverett! I'll follow up later with annotations support. Also, do you have any thoughts on how custom field support might best be implemented?
> I'll follow up later with annotations support.
In a separate PR? I think this one's big enough and pretty well ready to merge.
> Also, do you have any thoughts on how custom field support might best be implemented?
I'm assuming you know about [field templates](https://bugwarrior.readthedocs.io/en/latest/common_configuration.html#field-templates). Can you be a bit more specific about what you're trying to do?
> In a separate PR? I think this one's big enough and pretty well ready to merge.
Yes in a separate PR.
> I'm assuming you know about field templates. Can you be a bit more specific about what you're trying to do?
Sure. And this is also for a future PR. My redmine instance has custom fields on issues, for example we use a field called "GitHub Branch / PR" where one can paste in the URL to the relevant branch/PR on GitHub that relates to a particular Redmine issue.
This comes across in the `issues.json` like so:
"name": "GitHub Branch / PR",
I'm not sure I see from the field templates how I could set up my configuration to write the value of this field to a new UDA.