Bug 1030166
Summary: | Project type should be required for project creation | ||
---|---|---|---|
Product: | [Retired] Zanata | Reporter: | Ding-Yi Chen <dchen> |
Component: | Component-Logic | Assignee: | Ding-Yi Chen <dchen> |
Status: | CLOSED UPSTREAM | QA Contact: | Zanata-QA Mailling List <zanata-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 3.1 | CC: | damason, dchen, djansen, sflaniga, zanata-bugs |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-07-31 01:23:31 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1014944, 1030182, 1088737 | ||
Bug Blocks: |
Description
Ding-Yi Chen
2013-11-14 04:21:28 UTC
Bug 1014944 and Bug 1030182 are avoidable for new projects if this bug is fixed. However, I suggest we fixed Bug 1014944, 1030182 first. Otherwise it is harder to reproduce the environment required to reproduce those bugs. I don't think this is a bug - No Selection is a valid (albeit slightly confusing) choice. It is a bug because: 1. It confuses the user introduced Bug 1014944 and 1030182 2. The behaviour is inconsistent with maven client (which requires default-project-type) Unless we are planing to implement the project-typeless function in near future, it is still valid. (In reply to Ding-Yi Chen from comment #4) > 2. The behaviour is inconsistent with maven client (which requires > default-project-type) What do you mean? The Maven client doesn't care if the server's project type is null, it only requires that project type be provided via zanata.xml, pom.xml or the command line parameter. But I agree that this is a bug. As soon as project type was introduced on the server, it should have been made compulsory for new projects. Obviously it would be better if the user somehow didn't have to specify the type, but changing that would be an RFE. defaultProjectType is required for maven put-project mvn zanata:help -Dgoal=put-project -Ddetail [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building Maven Stub Project (No POM) 1 [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- zanata-maven-plugin:3.3.0:help (default-cli) @ standalone-pom --- [INFO] org.zanata:zanata-maven-plugin:3.3.0 Zanata Maven Plugin Zanata client for managing projects, publishing source text and retrieving translations. zanata:put-project Creates or updates a Zanata project. Available parameters: defaultProjectType Default Project type. Versions under this project that do not specify a project type will use this default. Valid values are {utf8properties, properties, gettext, podir, xliff, xml, file}. See https://github.com/zanata/zanata/wiki/Project-Types Required: Yes Expression: ${zanata.defaultProjectType} This behaviour appears to have been intentional, i.e. via the Web UI you don't have to specify the type as using the mvn client is not part of the workflow. If you don't use maven, this option is not relevant to you. This behaviour appears to have been introduced in 2e9a156e34e7e9f089e47ede54a047e27ef5febe as a fix to an accidental project type setting problem. If you want to specify the above as a "bug", then this is a massive oversight, simply because: - user can upload incorrect file types to a project (eg. .odt -> UTF8Prop) - using maven push/pull with files of the wrong type has wildly undefined results (eg. incompatible source are potentially deleted) - there is virtually no information for a web user as to what to do with .properties files - the zanata.xml should not be provided if it is not compatible with mvn/cli If all of the above was not intentional, then our project definition and handling is fundamentally broken and repairing this should be a high priority. T(In reply to Damian Jansen from comment #7) > This behaviour appears to have been intentional, i.e. via the Web UI you > don't have to specify the type as using the mvn client is not part of the > workflow. If you don't use maven, this option is not relevant to you. Please don't make the assumption that nobody will ever use client if the project is created in web UI. Even if project maintainer don't use maven, translators might. > This behaviour appears to have been introduced in > 2e9a156e34e7e9f089e47ede54a047e27ef5febe as a fix to an accidental project > type setting problem. > > If you want to specify the above as a "bug", then this is a massive > oversight, simply because: > - user can upload incorrect file types to a project (eg. .odt -> UTF8Prop) How do you know the uploads are incorrect if project type is not specified? If project type is set as UTF8 properties, it is clearly wrong to upload .odt. > - using maven push/pull with files of the wrong type has wildly undefined > results (eg. incompatible source are potentially deleted) That should be separate bugs. > - there is virtually no information for a web user as to what to do with > .properties files > - the zanata.xml should not be provided if it is not compatible with mvn/cli True, we don't show the help on the spot on how to upload source and translation on project create page. What do you think it (the project create page) should looks like? > If all of the above was not intentional, then our project definition and > handling is fundamentally broken and repairing this should be a high > priority. I agree that our project handling should be more streamline, however, enforcing the setting on project type is sufficient to solve the problem I put in bug description and comment #4. Migrated; check JIRA for bug status: http://zanata.atlassian.net/browse/ZNTA-477 |