Developers of Sympa

[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?

> > 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.


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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature