This project has moved. For the latest updates, please go here.

Export issue

Apr 2, 2015 at 3:16 PM

We have run into a problem when exporting the rules in xml form to another list made from a template from the original list. Here is the scenario:
in one of our first versions of the list we had a column named Helpy1
-we have changed the column and rules several times and in our newest version the column Helpy1 and the rules with that columns were deleted
-when exporting the xml to a list with the same columns, somehow the Helpy1 rule is still there although I deleted the column and the rules in the original list.
Although, most rules are perfectly transfered but a read only condition is not workin as it should.

Kind regards
Apr 2, 2015 at 8:16 PM
Edited Apr 3, 2015 at 2:48 AM
First, I'm assuming when you say 'export the rules in xml form' that you mean 'export the rules in JSON form', because the rules are never in XML in my solution? ;)

Now I don't have a lot to go on here, but my suggestion is to go back to the original list, open the SPEasyForms settings page, and click on the Verbose button. Look for stuff highlighted in red (in the properties pane and in the visibility rules and in adapters views). Are there an highlighted rules for Helpy1? What I suspect is that you deleted the column from the list without first deleting the rules or something like that. If you then reload the settings page, you will not see the rules, because I don't display rules that are not related to the current content type (I assume they're related to some other content type). So it will appear that the rules are gone if you're not in verbose mode, but they're still there. If that's not the case then I'm stumped.

Export doesn't really do anything all that spectacular. It's not building a configuration file on the fly or anything like that, it's just opening a new browser window and telling it to load the raw text file that is the configuration file. That's the reason why the export button is disabled if you have uncommitted changes, because export is only going to show you committed changes.

As for the read only condition that is not working as it should, I'd need a lot more information to even begin to speculate why in any deep and meaningful way. What is the rule? How is it supposed to be working? How is it actually working?

As a general rule, any time someone has trouble with a configuration that is migrated from one list to another, I'm going to guess that one or more columns in the source and destination list have different internal names. SPEasyForms uses only field internal names to find fields and manipulate the form. The reason for this is because I don't want some administrator to later break your configuration by doing some as innocuous as changing a display name. But like SharePoint, SPEasyForms usually displays display names, because that's all most administrators know.

So any time you're having a problem like this on importing a configuration, start checking the internal names of all of the columns involved. If it's a visibility rule, check the internal name of the column to which the rule is applied. Also, if it has conditions based on the value of one or more other fields, check the internal names of those columns. And when I say check them, I mean check them in both the source and destination list and confirm that they are identical.

The easy way to check the internal names is go to list settings and click on the column. It will go to FldEdit.aspx with some arguments like so:


What I'm looking for is the request parameter called Field, which in this case equals What%5Fx0020%5Fis%5Fx0020%5Fyour%5Fx0020%5Fq. So my fields internal name is What%5Fx0020%5Fis%5Fx0020%5Fyour%5Fx0020%5Fq ...well, sort of. It's URL escaped, so the internal name is actually What_x0020_is_x0020_your_x0020_q, which makes sense in a Microsofty way, because the field's display name is What is your quest?. But Microsoft converts this to What_x0020_is_x0020_your_x0020_q when I first save the field, because a) it replaces spaces and special characters with a hex code (i.e. x0020 is a space, so each special character becomes 7 characters in the resulting internal name including the two underscores) and b) if the resulting name is more than 32 characters it truncates it (which you can get to in a hurry if you had a lot of special characters, now each 7 characters long).

All of this is just a long winded way of getting to my general suggestion that if you are going to be doing forms customization, I suggest that you consider creating all of your fields without spaces or special characters first, which will create an internal name that makes sense to you later. Then change it to what you want it to display as, which won't affect the internal name. So for my example, I should have named the column WhatIsYourQuest, and then gone back and changed it to What is your quest?. That would have given me nice sensible internal and display names.

Anyway, the general suggestion is start checking the internal names for the affected columns in both lists, and let me know what you find.

Marked as answer by mcsheaj on 4/13/2015 at 11:20 AM