Hi,
Le 28/05/2014 14:59, Dionysis Fryganas a écrit :
On 28 May 2014 14:12, "Sylvain Beucler - Inria"
<sylvain.beuc...@inria.fr <mailto:sylvain.beuc...@inria.fr>> wrote:
>
> Hi,
>
> Le 28/05/2014 11:30, Dionysios Fryganas a écrit :
>>
>> I have constructed a few non-complete suggestions about the
project's import/export features that should be visible available in
the web interface.
>>
>> Import/Export placement and link associations
>> Project specific
>>
>> The plugin import and export features would be meaningful to be
placed in the project/admin section under the admin->tools tab.
>> If that is the default position (haven't looked into that) , as an
admin/user then it would be friendlier to have a separate
"import/export" tab under the admin section of the project.
>
> Remember the main criticism from ESR's blog post (the one that
obergix pointed you at):
> 1. Hosting Sites Are Data Jails
> Consequently import/export is available to everybody including
anonymous users.
>
> Of course, export of private data will be restricted to members with
read privileges. Anonymous users will be shown which type of
information they can export and which type are restricted.
>
> Bottom-line: it's not a user (not admin) feature, and it's mandatory
(all projects have it). It could be a new tab just like "SCM", and/or
it could be linked from the tools.
>
>
>> Site-wide
>>
>> For site-wide links I propose an additional link to be placed under
the "site admin" tab and specifically under the "site utilities".
>> If this is not too obvious, link to the plugin could be placed
under each category where it can provide an import/export mechanism.
>
> Note sure what site-wide import/export you're thinking of.
> IMHO the import/export is focused on per-project import/export, mass
import/export is a different task entirely.
Yeah, I understand that now! I got confused in the concept of who has
the right to access/export a projects private data.
The forge admin has all privileges, so he can go to a project page and
start an import/export from there.
>> Private projects
>>
>> My idea is to keep the plugin accessible from project or site
administrators, thus private projects can be exported/imported without
having to concern about access restriction.
>>
>> If that approach is considered as wrong. The plugin could check
keep track of each users permissions on the hosted projects and
present the UI features only to users that have right access.
>
> The second one sounds good.
> Also, remember that permissions need to be checked for each
resource: public bug tracker can contain private items (e.g. security
reports); public projects may request a private SCM repository too.
>
If I understand all the above correctly, In such a case the user will
be able to export every public data but skip the private data all
together?
So as another feature, there could be a table (or a multi select) to
show which data or categories (trackers, wiki pages, mailing lists,
etc.)can be exported and give also the user the option to mark the
ones to be exported.
You got it.
>
>> Plugin UI features
>> Generally speaking
>>
>> The plugin will follow the rest of the UI patterns used throughout
FusionForge.
>>
>> That is, select boxes for fixed values in order to limit user
confusion on what the plugin can provide.
>> For example possible select box fixed values could be, the format
to export the data to, or the platform from which the data will be
imported from.
>>
>> Specifically
>>
>> Although it might be a bit early to define the UI, as a future plan
we could define a few standard UI objects that will be present in the
import export plugin.
>>
>> The Platform to choose to import from as a select list. (Google,
GitHub, SourceForge, etc.)
>> The format that will be parsed (at least in the early stage of the
plugin. In the future it could auto-detect the format?)
>> The targeted object in FusionForge (again, should that be automatic
as well??)
>> A file input, to accept data for importation from uploaded files.
>
> This sounds good.
> Beware of clearly distinguishing import features and export features.
>
>> Plan for integrating features in the web interface.
>>
>> The integration can start by integrating each block that has been
build from the plugin's core.
>
> "core" is normally the non-plugin part of FusionForge (e.g.
src/common/include/).
> "plugin core" sounds like an oxymoron, can you elaborate?
Wrong expression used, what I meant is that the parts of functionality
that are added to the plugin will be added along with their UI
features, whenever applicable.
OK, good idea.
>> As soon as the first portion of the plug-in is implemented, the
features will also be added in the web interface.
>> First step is to implement the importation of data from different
platforms. This approach is proposed since FusionForge already
provides many ways to export the data.
>
> The easiest way to integrate this UI, for now, is add it in the
import/export plugin.
> The plugin can add a new tab in the project page, for instance.
Other developers can disable it if necessary during your development,
by not enabling the import/export plugin.
>
>> Regards,
>> Dionysis
>>
>> PS. These are my ideas concerning web UI integration so far, as
stated in the beginning of the mail, these ideas are not thought as
complete and are posted here for feedback which will be highly valuable.
>
> If my answers are clear to you, please update the wiki page accordingly.
Thank you, I will start on that ASAP!
> --
> Sylvain
--
Sylvain
_______________________________________________
Fusionforge-general mailing list
Fusionforge-general@lists.fusionforge.org
http://lists.fusionforge.org/cgi-bin/mailman/listinfo/fusionforge-general
