Pipe styling issues/enhancements

[tudorbarascu]

Hi @3nids

I believe the styling rules for pipes/conduites are broken.

For instance, for the first style line: fk_distributor = 1and "status_functional" = 't' there is no "status_functional`` column so the filter is bad.

Also, maybe the rules would benefit for a description as it's not clear enough what they do:

The fonctionel non-fonctionneland the actif inactif should be better described as the user may not understand the difference.

Any suggestions?

[haubourg]

Confirmed here status_functional does not exist in view nor anywhere in the db.
@3nids any idea of the right styling rules?

[3nids]

Status_functional is a joined field in qgis, not a field in the view.
Indeed functional should better described. The idea is to distinguish objects that are temporary not in used but would be print on the map from objects that are definitely out of order and would not be printed.

[tudorbarascu]

I had searched for the column in the joined layers and it wasn't there.
It's actually easy to see that it isn't there, just click the test button for the fk_distributor = 1and "status_functional" = 't' rule.

If you have that column then it must be in one of the layers (SIGE cadastral layers) that are dropped when loading the project.
@3nids Can you confirm?

[3nids]

sorry, I realized it's still in PR qwat/qwat-data-model#121
I will update this to merge

[haubourg]

fixed in 8f8ab9b
status_functionnal replaced by status_value_en

[3nids]

until now, the QGIS project was the SIGE project, that was the only way to keep it up to date.
I had some simplifications for the symbology of pipes to merge but cannot.
I will step away with the SIGE project from now on but I would have prefer to know it a bit in advance since I have to update the procedure on the users' computers (git repo) and I hope they did not print any plan with the updated project....

[haubourg]

Oh sorry Denis, I didn't know you used that direcly. I can revert that if you want to merge, changes are not heavy to redo by hand afterwards.
In the other hand, the project was broken for any newcomer to github's repository, which was quite misleading. Give me the green light for reverting!

[3nids]

Well, we discuss it at some point and It might be the right time to do it (separate our project in its own repo).
I will try to keep you inform of next changes to arise in our project, mainly in forms (use of conditional visibility of groups/tabs, and use of drag and drop for all layers) so you can keep main demo project up to date.
It would still be easy to bring back our project again. I just created my own repo as https://github.com/sige-riviera/qwat-sige

[haubourg]

BTW, If I assume it is the right time to add constraints to forms too, so that users don't face postgres constraints errors.
Target QGIS versions for other QWAT users is an important point to discuss. We now need to add minimum version requirements in the release log. Constraints will link us to 2.16 (with useability issues) or 2.18. What about conditional visibility and drag& drop?

@qwat/board : Hi board, did you fix a QGIS version target already inside your organisations or can this be raised to 2.18 for everyone? If some of you decided to stick with 2.14 LTR, we would probably have to handle different qgs version in parallel, which is pure double work by now. Opinions welcome.

[3nids]

for us, go for 2.18 (conditional visibility is 2.18)