Developers of Sympa

[IKEDA Soji <address@concealed>]

David,

2019/01/31 19:00、David Verdin <address@concealed>のメール:

> Hey Soji!
> 
>> On 31/01/2019 10:48, IKEDA Soji wrote:
>> 
>>> Something that, in my opinion, is still missing, is the keeping of the
>>> original request context. the only example I have about it the following:
>>> 
>>> When a subscription is moderated, once the subscription is validated,
>>> the action translates from "subscribe" to "add" and is therefore based
>>> on the "add" scenario. As it is not an addition, but the acceptance of a
>>> subscription, it shold not use "add" scenario.
>> I feel you look a bit confused.
>> 
>> It happens only in the case that "subscribe" scenario returns the
>> result "owner".  It means that owner must validate addition, and when
>> owner validates request, "add" scenario checks owner's privileges.
> 
> No, I understood that. But I don't see why the "add" scenario is evaluated.
> 
> "add" is used to allow people to add new subscribers without a subscription 
> request.
> 
> Therefore the scenaroi can allow anybody to do it, not necessarily the 
> owners.
> 
> In some weird situation, you could prevent owners from adding addresses and 
> let only another group do it. Will subscription moderation still work in 
> this case?

Sympa itself does not know the way to allow the other roles subscription 
moderation.  Preventing owners from adding address is preventing subscription 
moderation.

I suppose you are talking about impossible situation with current Sympa (and 
Sympa in the past).

>>> I strongly agree with Soji's approach of making the different interfaces
>>> some request containers. We want to do this for a long time, so it's
>>> great we are closing to this goal! This is the only problem I met with
>>> this. And it was in 6.2.32. And it might be fixed in the meantime.
>>> 
>>>> There are some issues:
>>>> 
>>>> - Implementation on delayed requests.
>>>> 
>>>>    With web interface, bulk approval of requests (such as
>>>>    DISTRIBUTE, SUBSCRIBE) can take long time and might cause
>>>>    browser timeout.
>>>> 
>>>>    One solution is to add a new spool to keep requests already
>>>>    approved (not requests to be approved -- it is there), and
>>>>    maybe another daemon process simultaneously flushes them.
>>>>    I'm not sure this solution is the best.
>>> I think it's probably the best solution. If I recall correctly, we
>>> already use it for validated messages which are stored in a specific
>>> spool. So the problem remains only for subscription.
>>> 
>>> The only problem I  could see with that is the delay: on the web
>>> interface, when we display a message stating that an action has been
>>> executed, people expect it to be finished.
>>> 
>>> Maybe a simple warning telling "if you requested to add a lot of users,
>>> it can take a fw minutes to complete. Please be patient.é
>> As I wrote above, the case of subscription does not matter:
>> It is appropriately authorized by "subscribe" scenario.
>> 
>> Then, at last the owner validates requests (being authorized by "add"
>> scenario), additions are actually performed --- and they will cause delay.
>> Yes, delay does matter.
>> 
>> Furthermore, validated requests have to know context of validation
>> (by whom and how validated) to report result to owners.  That is,
>> new spool (if applicable) should keep that contexts along with
>> requests.  I worry if it's a bit complex.
> 
> I think you misunderstood me; I was not talking about scenarios anymore. I 
> was elaborating about your idea for asynchronous requests.
> 
>> 
>> 
>>>> - On web interface (described in below).
>>>> 
>>>>>    - Refactoring datasources.  I want to start it in the end of this
>>>>>      year and probably may be done in the first half of next year.
>>>>>      The goal is to define simple interface between datasource and
>>>>>      GUI (vue and so on).
>>>> I started working on this point (with delay of a year).
>>>> A PR is submitted (See PR #516 https://git.io/fhOfR ), and I wish it
>>>> being closed before the next stable in March.
>>>> 
>>>> In the next step, I hope we will be able to start thinking about new
>>>> GUI.
>>> I have't looked it it yet. I'll comment later.
>>>> 
>>>>>    - Refactoring task manager and task spool. It will be done in the
>>>>>      next year.
>>>>>      The purpose is to rewrite fossilized code.
>>>> It has basically been done.  See PR #394 https://git.io/fNbVH .
>>> Not looked at it either, but it certainly needed.
>>>>>    - OO-based robots and configuration mechanism.
>>>>>      It would be better to be done on separate branch and be merged
>>>>>      into Sympa 7.
>>>> It has not been done.
>>> And it's very big work, which probably implies to change the
>>> configuration language.
>>> 
>>>> 
>>>> ### The other refactorings
>>>> 
>>>> I think code for these things should be refactored:
>>>> 
>>>>    - Scenarios
>>>> 
>>>>    - Families
>>>> 
>>>> Progress about these will be reported after more half year, around
>>>> June.
>>> Please note that Marc is currently working on a refactored code for
>>> scenarios, which has the added value of making the scenarios easily
>>> extensible.
>>> 
>>> He does this on a private repository of his, as you asked. He will
>>> present it when he feels it is good.
>> I've already started work on scenarios.  As I'm planning to merge
>> it in the next stable, I'll submit PR in Feb.
> 
> Cool. We'll see how Marc's work can fit in it.

I don’t understand what you say.  He is distancing from the community for a 
while, as far as I understand.

Regards,
— Soji

> 
> regards !
> 
> 
> David
> 
>> 
>> 
>>>> ### About web interface
>>>> 
>>>> Web interface has several problems, such as:
>>>> 
>>>> - Configuration editor.
>>>> 
>>>>    Functions to edit configuration (templates, scenarios, ...)
>>>>    looks not suit for requiest framework described above.  However,
>>>>    they are generally poor.  It would be better to be reconstructed.
>>>> 
>>>> - Web interface itself.
>>>> 
>>>>    It is a chunk of older codes, and on the whole a reinventing of
>>>>    the web application framework.
>>> As an excuse: it was written a long time ago, before the frameworks exist.
>>>>    Moreover it obviously has several problems giving raise to
>>>>    security risk (Note that all of CVE reports on Sympa in the past
>>>>    were related to web interface).
>>>> 
>>>> IMO we were happy if we could throw older codes away and start
>>>> implementing the new thing just now.  At least latter can be done.
>>>> 
>>>> I personally don't want to improve current web interface, but
>>>> only will close flaws and bugs (Of course I won't disturb the
>>>> others adding new features to it).
>>> I think Racke woud be great at this task!
>>> 
>>> However, it is rather large, so it must be hndled carefully.
>>> 
>>>>                                    *
>>>> 
>>>> That's all on my last half year.  Comments and suggestions are
>>>> very appreciated.
>>> You did a great work, setting aside my disagreement with the
>>> owners/editors removal from configuration files.
>>> 
>>> I think we have a way safer Sympa now than half a year ago.
>>> 
>>> I'll use the latest version in the future Sympa training, so we will
>>> have a lot of feedback from the latest features.
>>> 
>>> Best regards,
>>> 
>>> David
>> Regards,
>> -- Soji
>> 
>>>> Regards,
>>>> -- Soji
>>>> 
>>>> On Fri, 1 Jun 2018 13:44:25 +0900
>>>> IKEDA Soji <address@concealed> wrote:
>>>> 
>>>>> Hi folks,
>>>>> 
>>>>> Half a year passed.  I want to follow up the last post in December.
>>>>> 
>>>>> On Fri, 1 Dec 2017 11:43:33 +0900
>>>>> IKEDA Soji <address@concealed> wrote:
>>>>> 
>>>>>> Hi folks,
>>>>>> 
>>>>>> I want to describe what I have done in this half year, and what I
>>>>>> want to do in the future.
>>>>>> 
>>>>>> * Periodical releases of Sympa 6.2 have been done. Recently they
>>>>>>    were done by quarters[1] (if it is hard, releases may be done by
>>>>>>    half a year).
>>>>>> 
>>>>>>    I can do it at least for more one year.
>>>>> Ongoing.  Made 2 stable releases as planned (another 1 withdrawn),
>>>>> 1 patch release and 1 security fix.
>>>>> 
>>>>> The next stable release is planned at 21st June.
>>>>> 
>>>>>> * Refactoring:
>>>>>> 
>>>>>>    - Many functions were refactored to be moved to "request" modules.
>>>>>>      This sort of refactoring will continue in the next year.
>>>>>>      The goal of this is making wwsympa, sympasoap and sympa.pl be
>>>>>>      thin wrappers of "request" modules.
>>>>> I hardly could put it forward for this half year.  I spent time
>>>>> moving documentation from older site, fixing some bugs (especially
>>>>> things related to issue #11) and coping with security flaw.
>>>>> 
>>>>> Thus, my planned works described in below will evenly delay for
>>>>> half a year.
>>>>> 
>>>>>>    - Refactoring datasources.  I want to start it in the end of this
>>>>>>      year and probably may be done in the first half of next year.
>>>>>>      The goal is to define simple interface between datasource and
>>>>>>      GUI (vue and so on).
>>>>>> 
>>>>>>    - Refactoring task manager and task spool. It will be done in the
>>>>>>      next year.
>>>>>>      The purpose is to rewrite fossilized code.
>>>>>> 
>>>>>>    - OO-based robots and configuration mechanism.
>>>>>>      It would be better to be done on separate branch and be merged
>>>>>>      into Sympa 7.
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> -- Soji
>>>>>> 
>>>>>> [1] https://fr.wikipedia.org/wiki/Mod%C3%A8le:Solstice-%C3%A9quinoxe
>>>>> Regards,
>>>>> -- Soji
>>>>> 
>>>>> -- 
>>>>> 株式会社 コンバージョン
>>>>> ITソリューション部 システムソリューション1グループ 池田荘児
>>>>> 〒140-0014 東京都品川区大井1-49-15 アクセス大井町ビル4F
>>>>> e-mail address@concealed  TEL 03-6429-2880
>>>>> https://www.conversion.co.jp/
>>> -- 
>>> "Mieux vaut viser la perfection et la rater que viser la médiocrité et 
>>> l'atteindre."
>>> - Francis Blanche
>>> 
>>> 
>> 
> -- 
> "Mieux vaut viser la perfection et la rater que viser la médiocrité et 
> l'atteindre."
> - Francis Blanche
> 
>