#foswiki 2017-05-02,Tue

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
GithubBot[distro] vrurg pushed 2 new commits to Item14152: https://git.io/v98AL
distro/Item14152 28f8fd0 Vadim Belman: Item14152: Added possibility to get a list of inactive features....
distro/Item14152 a6cf48d Vadim Belman: Item14152: Implemented long forgotten feature compatibility check....
[01:21]
***GithubBot has left [01:21]
FoswikiBothttps://foswiki.org/Tasks/Item14152 [ Item14152: Implement OONewPluginModel proposal ] [01:21]
.... (idle for 18mn)
***ChanServ sets mode: +o Lynnwood [01:39]
..... (idle for 23mn)
GithubBot[distro] gac410 pushed 1 new commit to master: https://git.io/v98pI
distro/master 796ecf3 George Clark: Item13909: Merge branch 'Item13909'
[02:02]
***GithubBot has left [02:02]
FoswikiBothttps://foswiki.org/Tasks/Item13909 [ Item13909: Support expansion of standard macros during topic creation from template. ] [02:02]
GithubBot[distro] gac410 deleted Item13909 at 9dd90e8: https://git.io/v98p8 [02:05]
***GithubBot has left [02:05]
...................... (idle for 1h49mn)
GithubBot[distro] gac410 pushed 1 new commit to master: https://git.io/v94JO
distro/master 7f103a0 George Clark: Item13905: Merge branch 'Item13905'
[03:54]
***GithubBot has left [03:54]
FoswikiBothttps://foswiki.org/Tasks/Item13905 [ Item13905: I'd like a way to make FW-level comments in topics. ] [03:54]
...... (idle for 28mn)
GithubBot[distro] gac410 pushed 2 new commits to master: https://git.io/v94UL
distro/master 1fcd1df George Clark: Item13905: Need CREATE: in template macros for RegisterTests
distro/master 0951051 George Clark: Item13905: Comment plugin templates need CREATE: prefix...
[04:22]
***GithubBot has left [04:22]
GithubBot[distro] gac410 pushed 1 new commit to master: https://git.io/v94Uw
distro/master d050b7c George Clark: Item14349: Fix unit tests
[04:33]
***GithubBot has left [04:33]
FoswikiBothttps://foswiki.org/Tasks/Item14349 [ Item14349: EditRowPlugin Edit Table button not functional on IE 11. ] [04:33]
.... (idle for 16mn)
GithubBot[distro] gac410 pushed 1 new commit to master: https://git.io/v94Tf
distro/master bbca7ae George Clark: Item13905: More CREATE: prefixes on topic create
[04:49]
***GithubBot has left [04:49]
FoswikiBothttps://foswiki.org/Tasks/Item13905 [ Item13905: I'd like a way to make FW-level comments in topics. ] [04:49]
............... (idle for 1h10mn)
***ChanServ sets mode: +o MichaelDaum [05:59]
........... (idle for 54mn)
GithubBot[distro] MichaelDaum pushed 1 new commit to Item14288: https://git.io/v94qJ
distro/Item14288 3127c1a MichaelDaum: Item14288: improving height calculation of editor
[06:53]
***GithubBot has left [06:53]
FoswikiBothttps://foswiki.org/Tasks/Item14288 [ Item14288: rewrite to support pluggable edit engines ] [06:53]
GithubBot[distro] cdot pushed 1 new commit to master: https://git.io/v94qU
distro/master e99c735 cdot: Item13632: some niceties for report dialog usability - duplicated action buttons, and select/clear all buttons
[06:53]
***GithubBot has left [06:53]
FoswikiBothttps://foswiki.org/Tasks/Item13632 [ Item13632: Duplicate Report, Install and Remove buttons at end of New Extensions page ] [06:53]
.... (idle for 16mn)
GithubBot[distro] MichaelDaum pushed 1 new commit to master: https://git.io/v94mv
distro/master 246a12a MichaelDaum: Item14387: performance sorting template candidates
[07:09]
***GithubBot has left [07:09]
FoswikiBothttps://foswiki.org/Tasks/Item14387 [ Item14387: Improve performance sorting template candidates ] [07:09]
GithubBot[distro] MichaelDaum pushed 1 new commit to master: https://git.io/v94mZ
distro/master de109d9 MichaelDaum: Item14387: remove unneeded attributes
[07:13]
***GithubBot has left [07:13]
GithubBot[distro] MichaelDaum pushed 1 new commit to Item14288: https://git.io/v94mR
distro/Item14288 9b1c875 MichaelDaum: Merge branch 'master' into Item14288
[07:15]
***GithubBot has left [07:15]
........ (idle for 35mn)
ChanServ sets mode: +o cdot [07:50]
cdotMichaelDaum: the NatSkin "JazzyNote" style ignores all settings for the logo. Is this deliberate? Am I missing something?
WIKILOGOIMG, NATSKIN_LOGO, setting the logoUrl in the theme configuration, none have any effect.
[07:51]
MichaelDaumyea, it's a bad style [07:55]
cdotI worked around it by creating a new theme, effectively subclassing JazzyNote, but that really doesn't seem like the right approach. [07:55]
MichaelDaumnaughty naughty [07:55]
cdotso you recommend customato in preference? [07:55]
MichaelDauma skin overlay would have sufficed
yes
and a new one is in the making called "matter" ... lot easier on the eyes
[07:55]
cdotok, will see if I can configure that to requirements. JazzyNote is so close, frustrating. [07:56]
MichaelDaumjazzynote is pretty much old school, like websites looked like 10 years ago [07:56]
cdotheh; I'm not rising to that one [07:57]
MichaelDaumto change the way the logo is handled in jazzy note, set SKIN to foobar,nat and create a file templates/foswiki.foobar.tmpl which reverts what foswiki.jazzynote.nat.tmpl does by using the standard definition in foswiki.nat.tmpl
or just rm foswiki.jazzynote.nat.tmpl
[07:58]
cdotBTW a note on English usage. When you say "X in case of Y" it does not mean the same as "X in the case that Y"
for example "The screen will go green in case the green template is chosen", that does not mean the same as "The screen will go green if the green template is chosen"
best to avoid the use of "in case" or "in the case that" if possible.
Just noticed it a couple of times in your doc.
[07:59]
MichaelDaum是的主人 [08:02]
cdotفقط لا تفعل ذلك مرة أخرى!
;-)
[08:03]
MichaelDaum: it took me a while to figure out, but (I think) EOTC stands for "Expand On Topic Creation"
fair point about the configuration parameter, though. It's a bit of a horror.
[08:16]
MichaelDaumthen the param could well be named, um, ExpandOnTopicCreation [08:18]
cdotespecially since the code says: "unless ( !$Foswiki::cfg{DisableEOTC}..." - my grain hurts when I read that :-(
^grain^brain
[08:18]
MichaelDaumindeed [08:19]
.......... (idle for 48mn)
***ChanServ sets mode: +o cdot [09:07]
GithubBot[distro] cdot pushed 2 new commits to master: https://git.io/v94Cv
distro/master 17a1e91 cdot: Item13909: remove quadruple negation in option, add some better doc
distro/master fb5f1ca cdot: Merge branch 'master' of https://github.com/foswiki/distro
[09:08]
***GithubBot has left [09:08]
FoswikiBothttps://foswiki.org/Tasks/Item13909 [ Item13909: Support expansion of standard macros during topic creation from template. ] [09:08]
...................... (idle for 1h46mn)
***ChanServ sets mode: +o MichaelDaum_ [10:54]
..................... (idle for 1h43mn)
ChanServ sets mode: +o gac410 [12:37]
.... (idle for 19mn)
gac410Something really strange happened when I tried to merge item13905 branch last night. The diff applied to Templates.pm badly corrupted the module. [12:56]
***ChanServ sets mode: +o Lynnwood [12:56]
gac410After the merge conflicts, I had to "git checkout Item13905 lib/Foswiki/Templates.pm" accept the branch version of the module and discard the merged changes. [12:57]
FoswikiBothttps://foswiki.org/Tasks/Item13905 [ Item13905: I'd like a way to make FW-level comments in topics. ] [12:57]
gac410Even cherry-pick of individual commits broke the module. Really strange. It was deleting lines that were in both versions, and adding back in blocks of code that had been long since removed. [12:57]
cdot: If you are moving all of the compatibility settings in to a single tab, there are a few more to move LegacyRESTSecurity LegacyFormfieldNames And it would be best to remove the EXPERT tag now that they are all gathered into a common place.
Otherwise the person migrating has to - know to look for them - and then enable expert. Took me forever to find EOTC setting until I remembered search.
Also {AccessControlACL}{EnableDeprecatedEmptyDeny}
[13:03]
............. (idle for 1h0mn)
cdotgac410: ah, I searched for "Compatibility" but not "Legacy" :-( [14:06]
gac410;)
And "deprecate" too
[14:06]
cdotI removed the EXPERT tag, but then put it back. Not quite sure why. [14:07]
gac410With them all in a tab like that, and all expert, then it's all hidden - even the tab, so the admin doesn't even know that there are compatibiliy options. I do find myself missing stuff at times.
Too bad it's all/nothing on the CREATE: option. Sad to lose backwards compatibility on CommentPlugin. But I can't think of some easy way to expand everything conditionally -
[14:08]
.... (idle for 18mn)
foswiki_irc6Not sure if anyone got back to me before my PC rebooted, but I'm having an issue where I click save and continue and it's giving me a blank error at the top, anyone know how to see what the issue is? [14:29]
GithubBot[distro] gac410 deleted Item13905 at b80f83f: https://git.io/v94Ng [14:30]
***GithubBot has left [14:30]
FoswikiBothttps://foswiki.org/Tasks/Item13905 [ Item13905: I'd like a way to make FW-level comments in topics. ] [14:30]
gac410foswiki_irc6: Do you get any javascript errors, or could the server be redirecting. You might need to use the browser debug panels to see what happens when you click Save & Continue.
when you click save & continue, the javascript does a POST to the server. If that is getting redirected or failing for some reason, you'll get an error. Maybe misconfigured short URLs?
[14:31]
foswiki_irc6Hmm, it's doing a POST to .../rest/NatEditPlugin/save
Where do I go to check the plugins again?
[14:34]
gac410What did the POST return? [14:35]
foswiki_irc6[HTTP/1.1 404 Not Found 26ms] [14:36]
gac410System/InstalledPlugins will show you what's enabled.
What server are you using?
[14:36]
foswiki_irc6I'm the Windows server guy :( It says the plugin it's complaining about is installed [14:38]
gac410Ah... Did you rename your scripts to rest.pl view.pl ... etc..
Looks like NatEditPlugin has hardcoded the script names used in Javascript to "rest" and doesn't take into account the ScriptSuffix.
[14:38]
MichaelDaum: Opened Item14388 ... NatEditPlugin won't work on any platform where scripts are renamed to *.pl Probably will whack some hosting sites as well, not just windows. [14:48]
FoswikiBothttps://foswiki.org/Tasks/Item14388 [ Item14388: NatEditPlugin does not honor the ScriptSuffix seting ] [14:48]
gac410jquery.foswiki.js provides a utility function to get a properly constructed script url. Shouldn't that be used rather than concatenating it's own url? [14:54]
GithubBot[distro] gac410 deleted Item14023 at 4d72e01: https://git.io/v94ht [14:58]
***GithubBot has left [14:58]
FoswikiBothttps://foswiki.org/Tasks/Item14023 [14:58]
gac410cdot, are you done with the Item14323 branch? If so, I'll delete it. [15:00]
FoswikiBothttps://foswiki.org/Tasks/Item14323 [ Item14323: Update to latest TinyMCE version ] [15:00]
.... (idle for 16mn)
LynnwoodA user just pointed out to me that on a newly updated site (going from 1.1.10 to 2.1.3) that the revision number on some topics took a large jump. Is this a known phenomena?
It didn't happen to all topics, just some and I can see obvious reason why.
[15:16]
gac410Did you migrate to PlainFile store? Or use RCS data? [15:17]
Lynnwoodmigrated to PlainFile [15:17]
gac410Did they have attachments? I wonder if the convert tool updates for each attachment rev as well.
cdot would probably know best.
[15:19]
LynnwoodLet me see if the topic has attachments.
no attachments on this topic.
[15:19]
gac410hm no idea then. Maybe cdot knows. [15:20]
Lynnwoodtis odd...
In the META:TOPICINFO, it shows reprev="34" version="64"
Looking back at the history in raw view, in version 30, it show reprev as 29, but then version 31 it shows reprev="29" and then in version 31 it shows reprev="1"
[15:23]
gac410sounds like some of the topics have bogus reprev that's confusing the converter. [15:31]
Lynnwoodthat could be...
That kind of makes sense.
[15:31]
jastbut is it supposed to be looking at reprev when determining the revision number? [15:32]
LynnwoodSince it appears that it's not many of the topics, i'm not going to be too concerned. [15:32]
gac410Might be good to open a task documenting the issue, in case someone else runs into the same symptoms. [15:36]
GithubBot[distro] MichaelDaum pushed 1 new commit to Item14288: https://git.io/v9BkG
distro/Item14288 476b859 MichaelDaum: Item14288: reorganize logging; fixed search dialog
[15:43]
***GithubBot has left [15:43]
FoswikiBothttps://foswiki.org/Tasks/Item14288 [ Item14288: rewrite to support pluggable edit engines ] [15:43]
GithubBot[distro] MichaelDaum pushed 1 new commit to Item14288: https://git.io/v9Bkn
distro/Item14288 9d9397a MichaelDaum: Merge branch 'master' into Item14288
[15:44]
***GithubBot has left [15:44]
....... (idle for 33mn)
cdotgac410: yes, finished with Item14323 [16:17]
FoswikiBothttps://foswiki.org/Tasks/Item14323 [ Item14323: Update to latest TinyMCE version ] [16:17]
gac410Okay thx [16:17]
cdotthe converter ignores reprev
Lynnwood: how did you do the conversion?
[16:17]
GithubBot[distro] gac410 deleted Item14323 at 2cb7414: https://git.io/v9BYp [16:18]
***GithubBot has left [16:18]
Lynnwoodhey cdot - I think i just did it as described in the upgrade guide. [16:19]
cdotand do you have an example of "before" and "after"? [16:20]
LynnwoodIf you mean the actual topics and associated history files, yes. [16:20]
GithubBot[distro] gac410 deleted Item14301 at 7c91e29: https://git.io/v9BOW [16:20]
***GithubBot has left [16:20]
FoswikiBothttps://foswiki.org/Tasks/Item14301 [ Item14301: Implement ConfigurableCookieNamesAndPaths ] [16:20]
cdotit's possible that you found a topic that had an RCS version X, but a %META:TOPICINFO version of Y
have a look at the ,v
[16:20]
Lynnwoodthat's possible. I think what gac410 mentioned is also a possibility - i.e. that the RCS history had some strangness back in the history. [16:21]
cdotyes. If you were using RcsLite. I have found some scary anomalies in old histories.
depends how much time you want to spend tracking it down.
[16:22]
Lynnwoodi think it was something like that... and when the conversion happened, it sorted it out by starting at 1 and proceeding through all the changes, ignore the numbering in ,v file. [16:23]
cdotI doubt that. The conversion works by running two "live" foswikis, one using the "old" store and the other the "new" store. So whatever a "normal" foswiki with the old store saw, that's what the converter would see [16:24]
LynnwoodI'm will to accept that explanation. More important to me is how I'm going to manage a fix because I have approved versions that are off. [16:24]
cdotso if you try to "replay" the older versions in the RCS store, you are likely to see the same problem [16:25]
LynnwoodI will go back and look at one of the old histories and let you know what I find. [16:26]
cdotAFAIK there's is absolutely no way for the receiver (PFS) end of the conversion to insert new revisions [16:26]
Lynnwoodi don't think it did. [16:26]
cdotit *is* possible to recover damaged RCS histories, but it ain't easy [16:28]
Lynnwoodexcuse my ignorance but what is the "reprev" value suppose to represent? [16:30]
cdotgood question
a topic is marked "reprev" when a topic version is replaced by a replace-revision save e.g. within the time window
[16:32]
LynnwoodSo, if some does same and continue within the set time-window? [16:35]
cdotit's needed to tell the core that it can't do a three-way merge, when another user does a save of the topic after an edit that was based on a base revision that has been repreved by someone else
so, user A starts an edit on rev 100 that was just edited by user B. Then user B does another save within the reprev window, to create a new rev 100. Now, when A saves, the "base" revision where they started their edit has gone due to the reprev.
[16:35]
gac410There is also a specific admin-only function edit ?cmd=repRev .... It allows a revision to be changed "in-place" ... useful for ex, if a topic contains a password you need to remove without saving it into history.
(Not sure if it's the same thing though)
[16:38]
cdotwithout reprev, B's second edit would have created rev 101, and a three-way merge could be done - rev 100, A's edits, and rev 101. The reprev forces the merge to be 2 way instead (rev 100 and A's edits) and that's a lot less satisfactory.
gac410: nah, that's a different animal. Superuser muddy-boots.
[16:39]
gac410okay sorry [16:39]
cdotthe value of the reprev tag is the last version for which a reprev was done. It is not cleared when a reprev is *not* done, which is a bit naff and is the subject of a Task somewhere. [16:41]
GithubBot[distro] gac410 pushed 1 new commit to master: https://git.io/v9BGc
distro/master 0b2d6c8 George Clark: Item14342: Merge branch 'Item14342'
[16:43]
***GithubBot has left [16:43]
FoswikiBothttps://foswiki.org/Tasks/Item14342 [ Item14342: Implement Additive Topic ACLs feature. ] [16:43]
cdotthinking about it, it could get reset to 1. If the history was corrupt, and the save process thought the current rev of the topic was 1 when a reprev save was done. Hmmm, that might be a race condition. [16:43]
GithubBot[distro] gac410 pushed 1 new commit to master: https://git.io/v9BGz
distro/master fa0a7cd George Clark: Item14342: Fix a typo in the explanation
[16:44]
***GithubBot has left [16:44]
GithubBot[distro] gac410 deleted Item14342 at 0aee29f: https://git.io/v9BG7 [16:47]
***GithubBot has left [16:47]
..... (idle for 22mn)
ChanServ sets mode: +o cdot [17:09]
gac410CDot: I'm confused about the expansion option. This is what is says in configure UI now. "Disable automatic macros on topic template expansion:{ExpandSomeMacrosOnTopicCreation}" [17:21]
foswiki_irc7Just realized the chat window was frozen so I have no clue if anything else was said to me about the error I had :(
I have another issue now though, I added a skin and now when I try to edit perferences I get an error saying "Can't locate Imagepath in @INC (you may need to install the Image::Magick module) (@INC contains: C:path C:path C:path . C:path)" but I forget how to add modules
[17:21]
cdotgac410: that's right. Parse it as "Disable" "automatic macros" "on" "topic expansion" [17:22]
gac410foswiki_irc7: I opened a task: Item14388 ... Right now it doesn't look hopeful. Needs a bit of javascript work. [17:22]
FoswikiBothttps://foswiki.org/Tasks/Item14388 [ Item14388: NatEditPlugin does not honor the ScriptSuffix seting ] [17:22]
cdotbloomin natedit.... the cancel button is a NOP AFAICT. ANyone any idea why? [17:23]
gac410cdot, so the Variable says "Expand some macros" but description says "Disable expansion." So i'm still confused. [17:23]
cdotOh; another double negative I didn't unwrap
oops
[17:24]
gac410okay thanks. ;) [17:24]
cdotthe option is named correctly [17:24]
foswiki_irc7Thanks @gac410. Not a huge issue with the save and continue right now [17:24]
cdotthe text is wrong, though. It should be "Enable", ass you guessed. [17:24]
gac410foswiki_irc7: Unfortunately it will impact any javascript interaction with NatEdit, including attach Not sure what other things use the js interface. [17:25]
foswiki_irc7Hmm, I haven't run into any attaching issues other than not being able to attach until I save a new page, which would make sense [17:26]
gac410The traditional topic attach will work fine. (attach link in bottom bar) But using the editor to attach from within the editor panel will probably fail. Just guessing though from reviewing the code. [17:27]
foswiki_irc7Nah, that works too unless we're thinking different places. Once I edit a topic I can attach from that screen and save just fine [17:28]
gac410As far as ImageMagick That one is a bit nasty to get installed on Windows. I really don't know how to go about it. It is dependent on some non-perl code, the Image Magic utilities. That the perl module links to. It really is going to depend on the perl platform you installed.
foswiki_irc7: okay. Well there are two editors involved,., The Wysiwyg / TinyMCE editor uses a different set of dialogs. Those will indeed work fine.
Anyway, I've opened a task. May need help from another dev to actually fix it. I'm not much of a javascript guru.
[17:28]
foswiki_irc7Ah, I see [17:30]
gac410I hope we can get it fixed in 2.1.4 [17:30]
foswiki_irc7Alrighty, well so far in my daily use I haven't run into any other issues with that yet [17:31]
gac410okay good. You are indeed a pioneer we don't have many people reporting use on Windows server. We could really use a volunteer who could focus on that platform. windows/Apache and Windows/IIS [17:32]
foswiki_irc7I'm determined to get it working well enough to an extent on here haha. I'm only using it for an IT knowledgebase right now for my company, so it's nothing too involved other than a means to get our support documentation off a local server and have an easier way to find documentation
So skinning it will change the way it edits things too? I figued it would just use the default editing method
I could always edit web preferences with the default skin
[17:33]
gac410y, the NatEditor was added with an extension. It started out as an independent plugin. So it uses a skin to override the edit dialogs. [17:38]
cdot ... Just tested "cancel" on both trunk and 2.1.3, TinyMCE and NatEdit. Cancel worked fine in all 4 tries. [17:44]
***ChanServ sets mode: +o cdot [17:50]
foswiki_irc7How do I get to adding modules so I can mess about? [17:55]
gac410adding modules? Perl you mean? That is something done in your Windows / Perl installation - Active State perl and Strawberry perl each do their own thing. I really don't know. [17:56]
foswiki_irc7Yeah, I remember doing it via Perl but just forget how I got it opened [17:57]
gac410cdot - just replied after you left. I tested cancel on nat & tmce, trunk & 2.1.3 and it all worked.
Sorry I can't help you there foswiki_irc7 I don't have a windows system to explore.
[17:57]
cdotI'm finding it a nightmare to configure NatSkin on trunk at the moment.
the basics; without PageOptimizerPlugin, it simply doesn't get past rendering a simple page :-(
[17:57]
gac410Ah... NatSkin I can't help much with. We installed it on 2.1.3 on blog.foswiki.org, but michael did most of the setup.
I've never tried it on trunk.
[17:59]
cdotcdot is regretting it [17:59]
gac410A LOT of the optional dependencies are really not so optional. If you look at the blog.foswiki.org Installed extensions, that should give you a good idea of what you need. [18:02]
cdoty, I think I satisfied all the "optional" dependencies. But I've got something adding content after the closeing </html> on the page, and that's pretty basic [18:09]
gac410I had that issue when I first merged your Item branches - Templates.pm was toasted, and I had to copy in your version. But after fighting with the merge and finished off, it seemed clean. [18:10]
..................... (idle for 1h42mn)
LynnwoodA user just pointed out to me that FORMFIELD macro works differently in 2.1.3 then in 1.1.x in regards to referencing a field whose name includes a space. Previously %FORMFIELD{"Field Name"}% worked (who would have though - it never occurred to me to try it), but now it doesn't.
2.1.3 requires %FORMFIELD{"FieldName"}%. I did a quick search of task web and didn't find this reported.
[19:52]
gac410is it just the FORMFIELD macro, or do the other forms have issues
Hm reading the Data Form docs, it does seem that the space should be removed when internally looking up the field name.
[19:54]
LynnwoodI tried QUERY in 2.1.3 and it didn't work there either... but then i would not expect it to work. I just tested %QUERY{"Field Name"}% and it didn't work in 1.1.10 either. [19:58]
gac410I don't see anywhere in VarFORMFIELD or Meta->get() that would strip out spaces. hm [19:59]
LynnwoodIt's not obvious to me from reading either DataForms or VarFORMFIELD that this format should work, but sure enough it did in 1.1.9. [20:00]
gac410the implementation of the macro on 2.x is very different. [20:01]
Lynnwoodic [20:01]
gac410looks like cdot rewrote it in https://github.com/foswiki/distro/commit/296860fe7b [20:03]
Lynnwoodi can't make sense of it...
...or at least enough to see where it might normalize the field name
[20:07]
gac410it was significant restructuring. The new code just asks Meta->get() for the fieldname without any normailzation. [20:08]
looking at 1.1.10, I don't see where the normalization happens there either. Strange. [20:13]
Lynnwoodif you don't have an install of 1.1.x handy, i can show you an example. [20:13]
gac410I have a lot of versions loaded. Just not all are operational.
I'd be fearful of any fix lest it break 2.x systems that expect the space on both sides.
This is probably a good one to open a task and try to engage CDot and Michael tomorrow morning.
[20:14]
Lynnwoodsure
i'll post it shortly
[20:16]
gac410thx [20:17]
...... (idle for 27mn)
LynnwoodI did come up with a short-term work-around by re-defining FORMFIELD locally. [20:44]
gac410I'm surprised nobody has encountered this. Spaces are clearly allowed in formfield names. The other one that caught us by surprise was the added support for non-ascii fieldnames.
I looked to see if enabling legacy Formfield names might help you, but it doesnt impact space processing that I can tell.
[20:45]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)