@myabc we would like to proceed with the rails4 development as follows:
- Create a separate integration branch combining rails4 and release/4.3
- Merge the initial PR opf/openproject#2104 into said branch
- Merge rails4.1 and 4.2 in there once they are done
- Continually merge release/4.3 into said branch
- Create a QA instance for the MyProject configuration regarding said branch on which the QA is being done
- Try to merge the integration branch into release/4.3 before 4.3.0 is released. If not, it will be merged into dev when the update is complete.
That way we have the benefits of
- being able to merge rails4 into release/4.3. That would be harder if we where to merge rails4 into dev
- being able to easily determine the cause of a bug. That again would be harder when merging into dev
What do you think?
openproject-ui_components (deleted yesterday?) is dearly missed : opf/openproject#3169
does anyone have a local copy to at least find out if something was of interest there?
probably @myabc has, I think he initially made that repo...
For Angular fanboys: Is there a way to reach a parent angular form from within a directive? (to avoid the
closest('form') in https://github.com/opf/openproject/pull/3160/files#diff-1cd2a3cf3e9b8b73307fe6447273b91bR67, as the form attribute is undefined due to angular.
I have a local copy in the sense that I have some checkouts from bower. Will try to recreate the repo from that
@oliverguenther one way is to bind a directive to the form by attribute e.g. <form search-form-wrapper>, define a controller on that directive with a submit method, then require said controller in the input directive
@ulferts If those are git checkouts you should be golden, right?
@0xF013 Okay, but if said form doesn't require a controller in the current functionality, I'd argue closest is an acceptable, faster (my time) solution.
@oliverguenther I am not critisizing the ‘closest’ approach, just answering the question
although I would add some ‘throw’ statement if form is not present
@0xF013 didn't say you were :) Your input is very appreciated.
That is actually what I do not appreciate about the solution. Somebody will surely come to my desk in a couple of weeks and challenge me because I own the code now
we should probably ask @myabc if he has the repo and replace it
@machisuji Now there's a different error in the flapping cukes. Could it be due to some request being made without
X-Authentication-Scheme "Session" in the frontend ? That would cause rendering basic auth by default und thus obviously, a missing #main-menu.
Still, I wonder why I didn't see those cukes fail locally
@oliverguenther mh but before the PR the Basic scheme was the default response anyway, so I don't see how the PR could break it.
BTW: ui-components is still in active use in release/4.2 as well (as openproject.uiComponents)
(I don’t have write access to the opf repo any more)
You could just ask the github guys if it is possible to restore the repository ;)
within a small time frame it is possible as far as I know
@ulferts tbh I’m not a fan of the plan you outlined for rails4 integration. It seems to add unneeded complexity. Personally I would suggest keeping dev for mainline development and cut
release/4.3 when it’s ready, particularly as release/4.2 isn’t even out of the door yet.
In any case, it makes sense that the whole dev team starts creating new features with Rails 4 APIs as soon as possible.
It’s true (as @marutosi pointed out) that
release/4.3 should not go out with Rails 4.0.13, but it could reasonably be released with Rails 4.1.x.
There are also features/fixes that are not directly related to the Rails 4 upgrade, but that are dependent on it happening, e.g. https://community.openproject.org/work_packages/4996 - hence useful having Rails 4 in mainline sooner rather than later.
Thanks for the repo @myabc. I forked it now so my name is no longer in the line of fire