Better control over include_sympa_list. Moderation of includes.

[sivertkh]

Expected Behavior

Owners should only be allowed to include lists they own. For lists not owned by the owner, a list include request should be created. The include should only start to work after the second owner has accepted it.

Current Behavior

When include_sympa_list is activated, any owner can include any list on the server. This can be used to harvest the names and email addresses the list.

Context

List memberships can potentially be personal data. Lists for members in unions, special interest group ect.

[ikedas]

Hi @sivertkh, I have another idea: Adding new scenario setting to allow or reject inclusion by the other lists. Pros of this idea seems (1) list owners can easily withdraw approval of inclusion by changing scenario setting, and (2) in the cases with list services dedeicated to particular organization, inclusion may be allowed by default.

[sivertkh]

Hi @ikedas,

Thank you for your reply. Yes that will work for limiting inclusions, but what if an owner wants a list included i A but stop anyone from including it in a list B? One could use custom scenarios per list but that does not scale?

This might be more of feature request for Sympa 7 if it's difficult to do in Sympa 6. A scenarios solutions will certainly help:)

[ikedas]

Hi @sivertkh,

I thought of at least three options: Allow any, deny any and custom. If scenario controlled inclusion, named filter may be used for the third option. I don't know whether it is user-friendly or not.

[pveith]

Hi @sivertkh, hi @ikedas, from my point of view list as data source should be declared in the source list. Thus i would suggest having option in the source list (default: deny import from all; allow import from all; allow from specified list [is this where the named filter ikedas mentioned comes in to play?]). This would remove the need of communication within the system, as it should be clear what to do to include a list. As a second idea (i would favor this one), a moderation process could be used for list include. The owner of a list, who wants to import users, creates a request (by filling out the data source settings), which then can be rejected or allowed by the source list owner. That way the owners of the source list can easily decide in each case what to do. (Technically i would be inclined to create the requests in a new table "inclusion_request_table"; This table would then be used for moderation. If accepted by source list owner content would be copied to "inclusion_table". Thus the sync process could be used unchanged enabling this procedure to be implemented in a plugin even though i suggest this feature to be included in sympa main.) Hope that helps and would try to help implement this. EDIT: Third idea. It could be possible to change the setting from "import list from" to "export list to" and reuse the web interface? The source list specifies what should be exported and the target list just gets a checkbox to activate the import. This would solve the rights management on subscribers in my opinion.

[pveith]

As a workaround i used my isExporter-Plugin. I then customize the webtemplate for a configuration, i would like to hide from users, who are not in a specific group. In this case i installed a list named "sympa-importer" as a newsletter, where i store all user, who should be able to include sympa lists. And at the point in the edit_list_request.tt2 template where sympa_includes are handled, i check for the membership and show the configuration (user is in list) or a notice what to do to get this feature (user not in list). I could publish it, if someone does find it helpful besides me.