No more calling PHP code from LfMerge #173
Conversation
This is the first step towards being able to get rid of the RunClass code and not have our C# code call our PHP code.
Now that the MongoConnection knows how to update role views and user views, this is no longer needed at all.
rmunn
force-pushed
the
feature/no-more-runclass-usage
branch
from
471c0a1
to
f51090c
Compare
There was a problem hiding this comment.
looks good so far!
Reviewed 12 of 12 files at r1, all commit messages.
Reviewable status: 0 of 1 LGTMs obtained (waiting on @rmunn)
|
Just ran a test, and got Send/Receive to complete correctly, but the custom field ended up with a type of "basic" instead of "multitext". Should be pretty straightforward to figure out why, but this isn't quite ready to merge yet. |
Did a bit of debugging and found that in addition to MultiString, we can have a field type of String coming from FieldWorks for a custom field of the most common type, which should convert to "multistring" in LF.
|
Tested and working now, so now I can remove the bit from the Dockerfile that pulls in the web-languageforge image. That should make the lfmerge images much smaller and speed up the build time. Then it will be ready for review. |
There was a problem hiding this comment.
Reviewed 2 of 2 files at r2, 1 of 1 files at r3, 2 of 2 files at r4, all commit messages.
Reviewable status:complete! 1 of 1 LGTMs obtained (waiting on @rmunn)
The logic from this method has moved into MongoConnection
This PR finally implements the updateCustomFieldViews logic in LfMerge, as part of the SetCustomFieldConfig method in MongoConnection (which is where the logic belongs anyway). This will allow us to move the
lfmergepackage into its own container in Language Forge, instead of having it so tightly coupled to the PHP container.This change is