Collect Tryton references

Feature Ideas
1

At B2CK, we have a frequent request from leads to give references of Tryton in the same field.
So we think it will be great if the Foundation could collect such information and share it (I think it fit with the promotion mission).
I think we could add a cron task in standard trytond. This task will be activated as opt-in using the configuration wizard. The task will send to the Foundation server periodically (once per month) this information:

  • Name (required)
  • Contact email (required) + publish option
  • Country (optional)
  • Description (optional)
  • Version (optional)
  • List of activated modules (optional)
  • Number of users (optional)

The Foundation server will verify the email by sending a verification URL (like web_user module).
Once validated the information will be published on www.tryton.org (with search toolbar). If the data are not updated after a period (e.g. 6 months), the record will be deactivated.
In order to identify the installation/database, the task will generate a unique identifier (UUID4). The Foundation server will compare it with the stored hash to allow the update.
All communication will be done with SSL. And the task should not interfere with the normal usage of Tryton.

And of course we will respect of https://discuss.tryton.org/privacy

2 Likes
2

It sounds like a good Idea to me. However, I would separate the list of activated modules from the other information.

I would create one UUID for the contact information and another UUID for the list of activated modules so we guarantee that the list of modules is 100% anonymous. This would encourage people to publish the list of modules they have installed without forcing them to provide their company’s name. This information could be important for making certain decisions for Tryton.

Debian, for example, has the popularity contest: https://popcon.debian.org/

3

I do not see the point. If we want to collect only modules, we will need any way an email to validate.
The only extra requirement is the name which can be anything people wants. So I do not see any benefit to split the collection.

4

If the list is going to be published, we’d better not publish invalid names.

5

Please define what is an invalid name? People are free to name there setup as they want.

6

I supposed, that the Name they were sending was the name of the company but I see you expect something else. Then if the company name is not published I don’t see the point from a marketing point of view…

7

People will be what ever they want to name their instance. The main goal is that someone contacting them about the reference will be able to able to talk the right one thanks to the name.

8

Then we should probably name them “Instance name” so it’s clear that we are refering to it.

9

I think we should allow the user to share it’s data anymously by not publishing it’s email publicity on the foundation website.

I think this should be an option for sharing each of this features which by default we should check the version, and let the user opt-in for the modules and the number of users

10

We could also collect indexes usage statistic for Issue 5757: Make harder to create an index - Tryton issue tracker but also other database statistics. For now I only see pg_stat_user_indexes and pg_stat_user_tables.

11

Another option would be to use a Proof of work against the submitted data.
For example, we could add an incremental counter (could be just a timestamp or the date) and requires a sort of Hashcash.
This will avoid the requirement to validate the email address.