Redmine

Hi to all Redmine fans, users and developers.

I would like to propose a feature for a future version: the possibility to "share" projects between redmine instances. This post will just contain for now a brief concept. Most certainly, such a proposal will have to be split in several issues. Maybe further contributions to the concept, later the corresponding code, can lead to it. I started typing this as an issue, but then I thought this forum is a much more appropriate place to start.

Problem to solve:

• Different companies / teams need to sync on a certain project, but do use different redmine installations. They do not generally share details on users, except for those involved in the project.

It would be cool if either installation would be able to see progress at least on:

• issues
• timelogs
• notes
• news
• roadmap

of a project.

As a longtime redmine user and admin, thus knowing a bit the structure, I know this would be a major headache if all aspects are considered. But to give the thoughts a start..

A first implementation of such a federation could involve using a plugin and the REST API, with the following aspects (given server A and B):

• setting up federated servers in general preferences - they need a server-to-server authentication. Each connected server would have to be confirmed on either side and have a record in its own table.
• mapping of users between instances: either side would have to confirm the mapping from a user on one platform to the user representing the same person on the other side (e.g. A:bob to B:bob).
  This could be achieved by storing REST API tokens for A:bob -> B:bob. Those tokens, though, should be bound either to user+federated server or to user+federated server+project(s). That would give the flexibility to decide whether A:bob is generally mapped as B:bob or just to B:bob:projectX.
• setting up project sync: A:name of project on A to B:name of project on B
  Project settings could have the following modes:
  • master-master (both sides can read, update and delete)
  • master-slave (one side just gets the updates of the other)
  • finer grained settings would be of course adviseable
• handling of roles and permissions
  Permissions are probably the most complex thing to solve (who knows which roles have been defined on either side?) - but I think that the best way is to leave the whole role + permission assignment chapter to each side as much as possible.
  People on server A would have to live with the fact that once content is synced to B, they will (by design: different DB, different server, etc.) have no real influence on who can potentially read the information. The handling of private issues comes to mind here. There should be a toggle to enable/disable private issue syncing at all.
  That assessed, the code handling the POSTing, PUTting, and DELETing of content to the other side would still have to handle potential "access denied's" coming from the remote API, and accordingly display these to the local users.
  If, for example, B:alice is not allowed to update an issue but A:alice is, the issue on A should display that it is out of sync after saving.
• keeping track of where things come from
  I guess that to keep track of who changed what and where, there are two main roads:
  • adding a "foreign_id" for each entry in each table for each synced entity
    • the foreign_id could be either the numeric id of the table, or a composed one, involving <foreign server id>.<foreign item id>
    • or, limiting the whole synchronisation to one server per project, just the <foreign item id>
  • storing matching ids in one table involving fields as class (issue/project/news etc), local id, foreign server id, foreign id.

Of the two I would prefer the foreign_id with <foreign server id>.<foreign item id>, which I think corresponds more to the current normalization scheme.

I'm sure many other aspects have to be covered - but to start a discussion (hopefully also followed by the core developers!): any more ideas and opinions?

Best Regards,

Lorenzo