9 May
2018
9 May
'18
3:46 p.m.
Hi xwikiers,
Denis expressed to me some concerns about the type that should be
associated to Mail.MailConfig since it contains configuration data.
One important issue I see if that this page is primarily an admin
configuration UI which happen to also contains configuration data
(would have been much cleaner to store the data in a generated
document...) so I think the best for now is to keep the default type.
Since you are not supposed to go trough edit more to modify those
configuration data, the edit protection should not really affect users
in practice (no warning when using admin UI).
WDYT ?
--
Thomas Mortagne
9 May
9 May
3:53 p.m.
Hi,
On 9 May 2018, at 15:46, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Hi xwikiers,
Denis expressed to me some concerns about the type that should be
associated to Mail.MailConfig since it contains configuration data.
One important issue I see if that this page is primarily an admin
configuration UI
I don’t understand this sentence. MailConfig is not an UI and it doesn’t contain
configuration for UI. It contains config for the mail server, mail properties, etc. It
contains mail configuration data. Not related to UI.
which happen to also contains configuration data
(would have been much cleaner to store the data in a generated
document…)
Same, could you explain this more?
so I think the best for now is to keep the default
type.
Since you are not supposed to go trough edit more to modify those
configuration data, the edit protection should not really affect users
in practice (no warning when using admin UI).
We happen to have some Admin UI that changes the MailConfig page so I’m fine to use
‘default’ (i.e. to warn the users when they try to edit it).
The important aspect is that we don’t try to merge it when the admin upgrades the wiki and
there’s been changes brought to it (through the Admin UI), and I believe “default” will
achieve this.
Now we might have other *Config pages for which we’re currently lacking an Admin UI till
we provide such a UI, we’ll need to mark those as “demo” for now.
So ok for me for MailConfig (if I understood correctly).
Thanks
-Vincent
WDYT ?
--
Thomas Mortagne
4 p.m.
On Wed, May 9, 2018 at 3:53 PM, Vincent Massol <vincent(a)massol.net> wrote:
--
Thomas Mortagne
Hi,
MailConfig is the entry point used by admin UI to get the UI related
to mail configuration (indicated by several XWiki.ConfigurableClass
objects) so it is a UI element itself.
On 9 May 2018, at 15:46, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Hi xwikiers,
Denis expressed to me some concerns about the type that should be
associated to Mail.MailConfig since it contains configuration data.
One important issue I see if that this page is primarily an admin
configuration UI
I don’t understand this sentence. MailConfig is not an UI and it doesn’t contain
configuration for UI. It contains config for the mail server, mail properties, etc. It
contains mail configuration data. Not related to UI. which happen to also contains configuration data
(would have been much cleaner to store the data in a generated
document…)
Same, could you explain this more?
so I think the best for now is to keep the
default type.
Since you are not supposed to go trough edit more to modify those
configuration data, the edit protection should not really affect users
in practice (no warning when using admin UI).
We happen to have some Admin UI that changes the MailConfig page so I’m fine to use
‘default’ (i.e. to warn the users when they try to edit it).
The important aspect is that we don’t try to merge it when the admin upgrades the wiki
and there’s been changes brought to it (through the Admin UI), and I believe “default”
will achieve this.
Now we might have other *Config pages for which we’re currently lacking an Admin UI till
we provide such a UI, we’ll need to mark those as “demo” for now.
So ok for me for MailConfig (if I understood correctly).
Thanks
-Vincent
WDYT ?
--
Thomas Mortagne
4:14 p.m.
On 9 May 2018, at 16:00, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
On Wed, May 9, 2018 at 3:53 PM, Vincent Massol <vincent(a)massol.net> wrote:
Ok I understand now what you mean. Indeed we could have had another page for holding the
ConfigurableClass and thus separate the UI aspects from the data aspects.
Thanks
-Vincent
Hi,
MailConfig is the entry point used by admin UI to get the UI related
to mail configuration (indicated by several XWiki.ConfigurableClass
objects) so it is a UI element itself. On 9 May 2018, at 15:46, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Hi xwikiers,
Denis expressed to me some concerns about the type that should be
associated to Mail.MailConfig since it contains configuration data.
One important issue I see if that this page is primarily an admin
configuration UI
I don’t understand this sentence. MailConfig is not an UI and it doesn’t contain
configuration for UI. It contains config for the mail server, mail properties, etc. It
contains mail configuration data. Not related to UI. which happen to also contains configuration data
(would have been much cleaner to store the data in a generated
document…)
Same, could you explain this more?
so I think the best for now is to keep the
default type.
Since you are not supposed to go trough edit more to modify those
configuration data, the edit protection should not really affect users
in practice (no warning when using admin UI).
We happen to have some Admin UI that changes the MailConfig page so I’m fine to use
‘default’ (i.e. to warn the users when they try to edit it).
The important aspect is that we don’t try to merge it when the admin upgrades the wiki
and there’s been changes brought to it (through the Admin UI), and I believe “default”
will achieve this.
Now we might have other *Config pages for which we’re currently lacking an Admin UI till
we provide such a UI, we’ll need to mark those as “demo” for now.
So ok for me for MailConfig (if I understood correctly).
Thanks
-Vincent
WDYT ?
--
Thomas Mortagne
16 May
16 May
10:18 a.m.
On Wed, May 9, 2018 at 4:53 PM, Vincent Massol <vincent(a)massol.net> wrote:
Hi,
Note that on the merge side, the purpose of "default" is to explicitly
merge any updates.
"default: used to force the default. Edit and delete are not allowed and a
3-way merge is applied to the document during upgrades."
Perhaps a more appropriate type for this page would be:
"configuration: a document containing configuration. Edit is allowed and
the document is never upgraded."
...since, after all, the main purpose of Mail.MailConfig is to be a
configuration page, with some stray (and rather static, i.e. don't change
often) UI elements in it (ConfigurationClass) that need to be extracted to
a different page (and *that* page will be set to type "default").
On 9 May 2018, at 15:46, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>
wrote:
Hi xwikiers,
Denis expressed to me some concerns about the type that should be
associated to Mail.MailConfig since it contains configuration data.
One important issue I see if that this page is primarily an admin
configuration UI
I don’t understand this sentence. MailConfig is not an UI and it doesn’t
contain configuration for UI. It contains config for the mail server, mail
properties, etc. It contains mail configuration data. Not related to UI.
which happen to also contains configuration data
(would have been much cleaner to store the data in a generated
document…)
Same, could you explain this more?
so I think the best for now is to keep the
default type.
Since you are not supposed to go trough edit more to modify those
configuration data, the edit protection should not really affect users
in practice (no warning when using admin UI).
We happen to have some Admin UI that changes the MailConfig page so I’m
fine to use ‘default’ (i.e. to warn the users when they try to edit it).
The important aspect is that we don’t try to merge it when the admin
upgrades the wiki and there’s been changes brought to it (through the Admin
UI), and I believe “default” will achieve this.
Now we might have other *Config pages for which we’re currently lacking an
Admin UI till we provide such a UI, we’ll need to mark those as “demo” for
now.
Same here... semantically, those are "configuration" pages as well.
Side note: Now, I notice a weird thing in the definition of the
"configuration" type:
"Edit is allowed <note for Vincent: delete is disallowed. We should write
this explicitly to clarify> and the document is never upgraded."
...and I kind of understand why Vincent might have suggested "demo", which
says:
"Edit and delete are allowed and the document is upgraded only if it's not
been customized."
...which is something that should, IMO, apply to "configuration" types as
well, since it would make sense to keep using the default configuration
values of an application (whichever those are and however they evolve
across time), until we start customizing them.
i.e. "configuration" should be: allow edit, disallow delete and only
upgrade if there were no changes.
WDYT?
Side note2: Just a quick reminder that for configuration, in the best case
scenario (where we have no mixing of code with configuration data), the
default actions should be to merge, like all the other package managers out
there.
Thanks,
Eduard
So ok for me for MailConfig (if I understood correctly).
Thanks
-Vincent
WDYT ?
--
Thomas Mortagne
10:42 a.m.
On Wed, May 16, 2018 at 10:18 AM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
On Wed, May 9, 2018 at 4:53 PM, Vincent Massol
<vincent(a)massol.net> wrote:
We already discussed this in another mail and the rational is to not
change the behavior controlled by configuration when you upgrade
(other than the possible WTF effect it could also be very dangerous in
case of configuration involving things like rights). When you don't
modify the configuration it usually means you are OK with the
configuration, but you might not be OK at all with a new default
configuration. On dev side it also gives you the liberty to change the
default configuration drastically without the fear to break anyone
during upgrade because it will apply only for new installs. If you
want to move to the new default it's still possible either by using
some factory reset button if provided or use the history.
Hi,
Note that on the merge side, the purpose of "default" is to explicitly
merge any updates.
"default: used to force the default. Edit and delete are not allowed and a
3-way merge is applied to the document during upgrades."
Perhaps a more appropriate type for this page would be:
"configuration: a document containing configuration. Edit is allowed and
the document is never upgraded."
...since, after all, the main purpose of Mail.MailConfig is to be a
configuration page, with some stray (and rather static, i.e. don't change
often) UI elements in it (ConfigurationClass) that need to be extracted to
a different page (and *that* page will be set to type "default").
On 9 May 2018, at 15:46, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>
wrote:
Hi xwikiers,
Denis expressed to me some concerns about the type that should be
associated to Mail.MailConfig since it contains configuration data.
One important issue I see if that this page is primarily an admin
configuration UI
I don’t understand this sentence. MailConfig is not an UI and it doesn’t
contain configuration for UI. It contains config for the mail server, mail
properties, etc. It contains mail configuration data. Not related to UI.
which happen to also contains configuration data
(would have been much cleaner to store the data in a generated
document…)
Same, could you explain this more?
so I think the best for now is to keep the
default type.
Since you are not supposed to go trough edit more to modify those
configuration data, the edit protection should not really affect users
in practice (no warning when using admin UI).
We happen to have some Admin UI that changes the MailConfig page so I’m
fine to use ‘default’ (i.e. to warn the users when they try to edit it).
The important aspect is that we don’t try to merge it when the admin
upgrades the wiki and there’s been changes brought to it (through the Admin
UI), and I believe “default” will achieve this.
Now we might have other *Config pages for which we’re currently lacking an
Admin UI till we provide such a UI, we’ll need to mark those as “demo” for
now.
Same here... semantically, those are "configuration" pages as well.
Side note: Now, I notice a weird thing in the definition of the
"configuration" type:
"Edit is allowed <note for Vincent: delete is disallowed. We should write
this explicitly to clarify> and the document is never upgraded."
...and I kind of understand why Vincent might have suggested "demo", which
says:
"Edit and delete are allowed and the document is upgraded only if it's not
been customized."
...which is something that should, IMO, apply to "configuration" types as
well, since it would make sense to keep using the default configuration
values of an application (whichever those are and however they evolve
across time), until we start customizing them.
i.e. "configuration" should be: allow edit, disallow delete and only
upgrade if there were no changes.
WDYT?
Side note2: Just a quick reminder that for configuration, in the best case
scenario (where we have no mixing of code with configuration data), the
default actions should be to merge
like all the other package managers outthere.
Actually the default in dpkg (Debian) is to not touch the
configuration. You just get warning in interactive mode that you have
a conflict and you have the possibility to replace your customized
configuration file with the new default instead. No merge in default
system, not even as an option (we are bypassing standard configuration
file handling in XWiki package to get 3 ways merge support).
Thanks,
Eduard
>
> So ok for me for MailConfig (if I understood correctly).
>
> Thanks
> -Vincent
>
> >
> > WDYT ?
> >
> > --
> > Thomas Mortagne
>
>
--
Thomas Mortagne
2315
days inactive
2322
days old
5 comments
3 participants
participants (3)
-
Eduard Moraru -
Thomas Mortagne -
Vincent Massol