Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sceneri title changes #365

Draft
wants to merge 8 commits into
base: main
Choose a base branch
from
Draft

Conversation

taggart
Copy link
Contributor

@taggart taggart commented Jul 3, 2018

Here is a collection of scenari related stuff, mostly title.gettext changes to make things more consistent. There are a couple changes that could be considered related to #362 where an authenticated version of a type didn't exist. In those cases the patch adds one, but maybe it would be better to add the authentication to the existing non-auth version?

Feel free to just cherry pick whatever makes sense and also let me know if you'd prefer that I break things up into multiple PRs.

get rid of confusing send.editorkeyonlyauth which didn't do anything
create send.editorkeyauth type
clarify text
send.publickey is weird, it does a request_auth for all smtp, but
the user authenticating wouldn't need to be a subscriber/editor/owner/
listmaster, so would just need an account on the server?
OR have DKIM

This doesn't seem that useful, but if it is it should probably be named
send.publicauthdkim or something
@ikedas
Copy link
Member

ikedas commented Jul 3, 2018

@taggart, I feel we would be better to divide works: Adding auth versions (suggested by #362), and correcting titles (currently proposed here).

One idea: Instead of submitting single PR, how about opening another issue page to discuss about titles?

@qosobrin
Copy link
Contributor

qosobrin commented Jun 6, 2022

Why don't you have #179 into account? In my institution we ended by renaming scenari files with numeral prefixes. For example, the add menu now shows these scenarios in this order:

add.auth            restricted to owner with authentication
add.authdkim        restricted to owner without authentication if DKIM signature is OK.
add.closed          add impossible
add.owner           add performed by list owner does not need authentication
add.owner_notify    add performed by owner does not need authentication (notification)
add.ownerdkim       add performed by list owner does not need authentication if DKIM signature OK

But if you rename the scenari files from public to restricted you will get something like:

add.1-owner         add performed by list owner does not need authentication
add.2-owner_notify  add performed by owner does not need authentication (notification)
add.3-ownerdkim     add performed by list owner does not need authentication if DKIM signature OK
add.4-authdkim      restricted to owner without authentication if DKIM signature is OK.
add.5-auth          restricted to owner with authentication
add.6-closed        add impossible

This makes life easier for users to select the correct scenario since now they know the scenarios proposed in the drop-down menus have a logical order. And furthermore, an exercise like this will allow you to identify scenarios that are useless or are equal (for example, add.authdkim is basically the same as add.ownerdkim and one of them could be removed).

Best regards,

@ikedas
Copy link
Member

ikedas commented Jun 7, 2022

@qosobrin , I think @taggart does not propose about ordering of the scenarios.

@ikedas ikedas changed the base branch from sympa-6.2 to main November 23, 2022 05:45
@ikedas ikedas marked this pull request as draft September 7, 2024 01:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants