Question : wich date format is the most relevant in DocTypes ?

In the bills docType, the specified format is :

"date: {date} - Date the bill was emitted, a string formated (what you get with a new Date().toString())"

But Date().toString() seems not relevant :

• the ECMScript 2015 specification says "Return an implementation-dependent String value that represents tv as a date and time in the current time zone using a convenient, human-readable form."

• the ECMScript 2016 draft specification says :

  Let t be LocalTime(tv).
  Return the string-concatenation of DateString(t), the code unit 0x0020 (SPACE), TimeString(t), and TimeZoneString(tv). "

To help the decision :

• In the meta data of docType, the expected format date is ISO8601 (see here)
• momentjs can be considered as the standard in JS and has also opted for ISO8601 by default :

moment().format(); // "2014-09-08T08:02:17-05:00" (ISO8601 format YYYY-MM-DDTHH:mm:ssZ)
moment.utc().format(); // when in UTC mode, the default format is governed by moment.defaultFormatUtc which is in the format YYYY-MM-DDTHH:mm:ss[Z]. This returns Z as the offset, instead of +00:00.

So, what is the most convenient date format in JS for DocTypes ?

• [Date().toISOString()](https://devdocs.io/javascript/global_objects/date/toisostring) ?
• [Date().toUTCString()](https://devdocs.io/javascript/global_objects/date/toutcstring) ?
• other ?

index.js:

export const FILES_DOCTYPE = 'io.cozy.files'
export const BANK_ACCOUNTS_DOCTYPE = 'io.cozy.bank.accounts'
export const BANK_OPERATIONS_DOCTYPE = 'io.cozy.bank.operations'
export const PHOTO_ALBUMS_DOCTYPE = 'io.cozy.photos.albums'

In Cozy app:

import {  FILES_DOCTYPE } from 'cozy-doctype'

Not to forget.

import { Document } from 'cozy-doctypes'
import { TRIGGER_DOCTYPE } from 'doctypes'

// TODO to remove when 
class Trigger extends Document {}
Trigger.doctype = TRIGGER_DOCTYPE

export default Trigger

See https://github.com/cozy/cozy-store/pull/592/files

En relisant la documentation des doctypes bancaire je me suis rendu compte que l'on n'affichait pas d'exemple ce qui peut poser un problème de compréhension.

Je serai pour que l'on mette un exemple pour chaque doctype.

Voici ce que ça donnerai pour un compte en banque:

{
  "label": "Livret A Isabelle",
  "institutionLabel": "La Banque Postale",
  "number": "123123123",
  "balance": 11635.12,
  "iban": "FR1420041010050500013M02606"
  "type": "Savings"
}

Vous en pensez quoi ?

I am working on a Deezer connector. Currently, we only have apps that can consume invoices as PDF (Drive) and bills (Banks). But a connector like Deezer finds all its potential by fetching albums, playlists and tracks.

Some other providers (randomly Spotify) would fetch exactly the same data, so I was wondering if it would be OK to think a little about theses doctypes.

For playlists, there's the M3U open file format that may be a good basis.

The Tricount and Splitwise connectors are bringing shared expenses into the realm of Cozy.
For now, they are saved in a format very close to how they are consumed by their respective web-apps. For shared expenses to be interesting from a Cozy point of view, and to be exploitable in the same way by Banks for example, we should have a common format for this kind of expenses.

Here are two examples of shared expenses, one from Tricount and one from Splitwise. I do not have now the time to think of a common format, I am putting this here not to forget :)

com.tricount.expenses

{
  "_id": "5b59918ce0ecdfefb90b76ac17014b5c",
  "addedBy": {
    "email": null,
    "id": 22774410,
    "name": null
  },
  "amount": 5.5,
  "amountOfParts": 1,
  "currency": "€",
  "id": 71467317,
  "name": "fou de pâtisserie",
  "payedBy": {
    "email": null,
    "id": 22774408,
    "name": "Patou"
  },
  "repartition": [
    {
      "amount": -1,
      "amountOfPart": 1,
      "user": {
        "email": null,
        "id": 22774410,
        "name": "Py"
      }
    }
  ],
  "tricountId": 5697832
}

com.splitwise.expenses

{
  "_id": "0f3d1d1e6e66f7a4ace61081f30377e4",
  "category": {
    "id": 18,
    "name": "Général"
  },
  "comments_count": 0,
  "cost": "22.0",
  "created_at": "2017-11-07T08:54:03Z",
  "created_by": {
    "first_name": "maureen",
    "id": 999663,
    "last_name": null,
    "picture": {
      "medium": "https://splitwise.s3.amazonaws.com/uploads/user/avatar/999663/medium_P7211233.JPG"
    }
  },
  "creation_method": "split",
  "currency_code": "EUR",
  "date": "2017-11-07T08:53:46Z",
  "deleted_at": null,
  "deleted_by": null,
  "description": "Biocbon",
  "details": "",
  "email_reminder": true,
  "email_reminder_in_advance": null,
  "expense_bundle_id": null,
  "friendship_id": null,
  "group_id": 2468147,
  "id": 279457166,
  "next_repeat": null,
  "payment": false,
  "receipt": {
    "large": null,
    "original": null
  },
  "repayments": [
    {
      "amount": "7.33",
      "from": 975791,
      "to": 999663
    },
    {
      "amount": "7.33",
      "from": 2752687,
      "to": 999663
    }
  ],
  "repeat_interval": "never",
  "repeats": false,
  "transaction_confirmed": false,
  "transaction_id": null,
  "transaction_method": "offline",
  "updated_at": "2017-11-07T08:54:03Z",
  "updated_by": null,
  "users": [
    {
      "net_balance": "-7.33",
      "owed_share": "7.33",
      "paid_share": "0.0",
      "user": {
        "first_name": "paulpeyret",
        "id": 2752687,
        "last_name": null,
        "picture": {
          "medium": "https://splitwise.s3.amazonaws.com/uploads/user/avatar/2752687/medium_e7c65326-4fe5-45c4-aeb5-14e6ff9f2548.jpg"
        }
      },
      "user_id": 2752687
    },
    {
      "net_balance": "14.66",
      "owed_share": "7.34",
      "paid_share": "22.0",
      "user": {
        "first_name": "maureen",
        "id": 999663,
        "last_name": null,
        "picture": {
          "medium": "https://splitwise.s3.amazonaws.com/uploads/user/avatar/999663/medium_P7211233.JPG"
        }
      },
      "user_id": 999663
    },
    {
      "net_balance": "-7.33",
      "owed_share": "7.33",
      "paid_share": "0.0",
      "user": {
        "first_name": "Patrick",
        "id": 975791,
        "last_name": "Browne",
        "picture": {
          "medium": "https://splitwise.s3.amazonaws.com/uploads/user/avatar/975791/medium_2ecb75c1-a460-45ca-a80a-3d6f14c517d4.jpg"
        }
      },
      "user_id": 975791
    }
  ]
}

Il manque la documentation pour les doctypes suivant :

• io.cozy.accounts
• io.cozy.apps
• io.cozy.konnectors
• io.cozy.settings

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two-Factor Authentication, make configure the auth-only level is supported. semantic-release cannot publish with the default auth-and-writes level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.

Good luck with your project ✨

Your semantic-release bot 📦🚀

Les remboursements et factures sont stockés dans les io.cozy.bank.operations de cette manière :

var operation = {
  amount: 50,
  reimbursements: [
    { amount: 10, operationId: '123456', billId: '789456' },
    { amount: 20, operationId: '123457', billId: '789457' }
  ],
  bills: [
    'io.cozy.bills:2',
    'io.cozy.bills:3'
  ]
}

Les remboursements et les bills sont stockés de deux manières différentes alors que c'est presque la même chose. On ne peut pas savoir non plus facilement (sans fetcher les factures) la somme des montants des factures d'une opération, par exemple pour savoir si on peut encore rajouter une facture pour cette opération bancaire.

Proposition: stocker les factures de la même manière que les remboursements, avec un array d'objets contenant l'id de la facture et son originalAmount. Le risque de déviation ces données et les données originales de la facture sont très faible vu que le montant d'une facture ne change jamais.