Created on 2022-07-09 22:15 by rouilj, last changed 2022-07-09 22:15 by rouilj.
|msg7602||Author: [hidden] (rouilj)||Date: 2022-07-09 22:15|
https://en.wikipedia.org/wiki/Networked_Help_Desk is an open standard allowing multiple issue tracking systems (rt, jira, zendesk, ..._) to share and synchronize information. The main web site is: http://networkedhelpdesk.org and the spec is at http://networkedhelpdesk.org/rfc/ The protocol is rest over http and json. With the merging of the rest interface and the ability to extend it this should be doable. They have a few requirements such as a UUID that uniquely identifies a ticket/request across systems. They define this as a sha1sum over update_url/type/id so issues.roundup-tracker.org/rest/sharing/issue/2 for sharing issue 2. Similarly users can be shared as the authors of comments. Sharing relationship is on a per ticket basis so this might add a requirement to extend a schema with an agreement multilink allowing 1 ticket -> many agreement relations. Also sharing relationships can be full or partial. The sender determines what can be done. It looks like the perms are: sender -> receiver full delegation: receiver can add comments: public (customer viewable) and private (not cust. viewable) (in roundup all are public, but a tracker can be built to support private comments) status on receiver side is synched to sender sender -> receiver partial delegation: receiver can send only private comments status is not synched This should be doable with the current roundup permission code. Need to add a validator that authenticates the user, verifies that there is a full/partial delegation and creates/sets as appropriate. It has its own authentication mechanism, so using JWT won't work. However for establishing agreements, jwt could be used to permit the sender to create an agreement invite/agreement modification request. Consider core changes/refactoring to allow for authentication plugins if modification via interfaces.py is not practical. The protocol uses POST for new issue creation and PUT for update. They allow incomplete PUT's where a missing value implies no change to that value as opposed to unsetting the value. This is what Roundup's interface permits as well. Using PUT for creation and PATCH for updates is suggested. In our case POST would always be used for creation since PUT must be used against an existing URL. PATCH should work as expected. It looks like users may be created as the result of a share. So the author for a comment update from a jira system will have a uuid for the user in jira and a name. This user will need to be created in roundup similar to how we autocreate users on email reception from unknown users. There is a mechanism for attaching files. It provides a url and a name. A Get on the URL retrieves the contents of the file on the update origin. Authentication credentials have to be included in the URL if authentication is needed. Custom fields ae supported. They suggest name spacing the field names. How mapping is done is not specified. Open questions: formatting of comments, what formatting language is used? Is everything turned into plain text or is markup (e.g. markdown/rst/jira) included? If the status has 5 values in jira but 7 in roundup, how are these mapped? The RFC defines only 3 states: "open", "pending", and "solved".