[Nicolas Noullet]

Hi, thank you for your suggestion! That is a very good idea. For the record, we are currently putting the last touch on a new UI for iceScrum. It will not offer the “attach / detach” anymore, at least in the first versions. However, we will try to include the “Focus” view for Tasks!

Bonjour, merci pour votre suggestion ! C’est une très bonne idée. Pour information, nous sommes en train d’apporter les touches finales à une nouvelle interface pour iceScrum. La fonctionnalité “attacher/détacher” ne sera plus proposée, au moins dans les premières versions. Cependant, nous allons essayer d’intégrer la vue “Focus” pour les tâches!

Très bonne journée à vous aussi !

[Nicolas Noullet]

Hi,

Glad to know that it works now. Thank you for the detailed feedback for the community, that may help someone!

For the record, the R6 version of iceScrum was using HSQL, while the v7 uses H2 by default. While being a bit safer, H2 is still not suited for production.

[Nicolas Noullet]

Hello,

Which version of iceScrum do you use?

Versions 7.* don’t use HSQL by default, but H2 instead. Thus, you have to pick an H2 driver in the tools you tried.

The user / password you tried are correct. By the way, you may notice that these credentials are far from secure, that is part of the reason why we strongly recommend switching to an external DBMS. The other reason is that the storage system of H2 is more prone to loosing data than other DBMS.

[Nicolas Noullet]

You should have received an email!

For the record, one option is the one mentioned in the post you linked: using two different system users to start the two different installations of iceScrum concurrently.

[Nicolas Noullet]

Hi,

If you use a proxy to define the SSL connection then the proxy configuration is the same regardless of the distribution.

The only part that is dependent on the distribution is the one where the distinction is made in the documenation:

Tomcat + icescrum.war:
Add the scheme and proxyPort attributes to your connector in server.xml: (…)
icescrum.jar:
Add the httpsProxy=true option in the startup command.
Docker:
See the corresponding documentation.

[Nicolas Noullet]

Hi,

Do you use the iceScrum .war or .jar distribution?

While the SSL connection could be configured at the iceScrum level, we usually recommend using a “reverse proxy” in front of iceScrum to handle it. The upside is that this is a very common thing to do so people usually have experience doing it and many resources are available online.

The two most popular reverse proxies are Apache and Nginx. Our documentation provides insights about how to configure them for iceScrum: https://www.icescrum.com/documentation/reverse-proxy/.

Please note that configuring a system to be used in production, especially in a secure fashion, requires a specific set of knowledge and skills (from the DevOps / System administration / Operations fields…).

Once the proxy is properly configured, you need to tell iceScrum that it will be accessed through https: https://www.icescrum.com/documentation/reverse-proxy/#https.

[Nicolas Noullet]

Hi Thomas,

Thanks again for your report.

A cache configuration had been changed on the Docker Hub build so that the latest build used the previous version of iceScrum (7.35.1) that was cached instead of the latest (7.35.2). This problem has been fixed and it should not happen again.

You can now use docker pull icescrum/icescrum in order to retrieve the proper latest version of iceScrum which is 7.35.2.

Kind regards,

Nicolas

[Nicolas Noullet]

Thomas,

In your case there is indeed no risk of conflict because of the data synchronization, but this is a very specific use case. If we provide an API endpoint then we must ensure that it works for the most common use cases, and in such cases conflicts may very well occur.

Anyway, could you tell me more about the use of this server duplication? What is it used for? If the whole server is synced then it would be more efficient to sync the database and the directory structure (attachments).

[Nicolas Noullet]

Hi Thomas,

Yes it is possible via the UI, but the reason is that once the project is imported the UI interactively asks several questions to the user in order to resolve the conflicts. Such resolution would have to be handled by the client code and it would be way less trivial than usual REST operations and human arbitration may be needed.

Can you tell me more about the motivation behind this usage of exports? What are you trying to achieve?

Thanks!

[Nicolas Noullet]

Hi,
Not this is not possible, this is one of the very few services that are hard to offer as a web service as it is interactive (conflicts must be resolved if the projects conflicts with existing data, and the conflicts are detected only after the project has been uploaded).

[Nicolas Noullet]

Hi,
Thank you for your report, this is a bug!

[Nicolas Noullet]

Bonjour,

Merci pour ce rapport de bug ! Il nous a également été remonté par d’autres utilisateurs. Une toute nouvelle UI d’iceScrum sortira bientôt et elle règlera entre autres ce problème.

Bonne journée,

Nicolas

[Nicolas Noullet]

Hello Stefan,

I think you refer to an “editable” roadmap, in which case it is not possible at the moment. The only duplication that can occur is making a read only “snapshot” of the live roadmap.

However, I understand that it would be cumbersome to have to enter everything again in your new editable roadmap, so we can exceptionally do the duplication for you if you want. I’ll get in touch with you in private in order to consider this option.

[Nicolas Noullet]

Hi Chris,

No problem 🙂

Regarding welcoming external contributions, my answer here: https://github.com/icescrum/iceScrum/issues/16 is still relevant. We would really like welcoming contributions but we have to invest our resources on other priorities, for instance the ongoing UI redesign, in order to stay alive and relevant.

That being said, we have implemented new performances improvements in the second-to-last version of iceScrum so this matter is still important for us.

Thanks for the numbers, this is what I would call a big project, and performance is worsened by that. If your users have a bad experience, then there is a simple and effective workaround: for the next release, creating a brand new iceScrum project to continue managing the developments. The history will still be available in the old project. Regardless of the tooling matter, we have the chance to coach agile teams and we have observed on may occasions that a “fresh start” is often very beneficial for the Product Owner and the team, and in turn for the product and its users. It does not detract from the fact that performance should still be improved, but if there is a way for your team to get a better experience then it is interesting to consider it.

[Nicolas Noullet]

Oh I see, I had a doubt when answering your first question.. it seems we are not talking about the same thing! Your question was about versioning of iceScrum items, whereas I answered about the link between code versioning in Git/SVN and iceScrum items.

Can you provide a simple example of what could go wrong and would require a full rollback, just to be sure that I understand your needs?

[Author]

Posts