From interchange at hertell.com Sun Dec 4 09:10:25 2016 From: interchange at hertell.com (=?UTF-8?B?UmVuw6k=?=) Date: Sun, 4 Dec 2016 11:10:25 +0200 Subject: [ic] Bug in the admin-UI Message-ID: Hi, I found a bug in the Admin-UI that gave an 500 Internal Server Error when downloading tables from the Table Manager (admin/gentable). PJ suggested to add an Autoload to the catalog_afer.cfg, and this fixed the problem. I created a pull-request @github with a patch. https://github.com/interchange/interchange/pull/105 Ren? From peter at pajamian.dhs.org Sun Dec 4 20:13:00 2016 From: peter at pajamian.dhs.org (Peter) Date: Mon, 5 Dec 2016 09:13:00 +1300 Subject: [ic] Bug in the admin-UI In-Reply-To: References: Message-ID: <1e797c05-b858-0bb9-4df0-3bc34eca8f33@pajamian.dhs.org> On 04/12/16 22:10, Ren? wrote: > I found a bug in the Admin-UI that gave an 500 Internal Server Error > when downloading tables from the Table Manager (admin/gentable). PJ > suggested to add an Autoload to the catalog_afer.cfg, and this fixed the > problem. > > I created a pull-request @github with a patch. > > https://github.com/interchange/interchange/pull/105 The AutoLoad is not necessarily what I would recommend for a permanent fix. The issue is that the ui_download ActionMap makes a call to $Tag->if_mm, which attempts to open the access table. Because it's being run in a Safe container it can't do so unless the table is opened ahead of time, which it isn't for the actionmap. The AutoLoad is a bit of a sledgehammer approach because it pre-loads the access table for every page, not just the ActionMap, but it does confirm (and fix) the issue. Other solutions would be to move the ActionMap to global code, or rewrite it so that it pre-opens the table itself, possibly by using ITL with a [perl access] tag instead of a sub. Peter From racke at linuxia.de Mon Dec 5 08:27:37 2016 From: racke at linuxia.de (Stefan Hornburg (Racke)) Date: Mon, 5 Dec 2016 09:27:37 +0100 Subject: [ic] Bug in the admin-UI In-Reply-To: <1e797c05-b858-0bb9-4df0-3bc34eca8f33@pajamian.dhs.org> References: <1e797c05-b858-0bb9-4df0-3bc34eca8f33@pajamian.dhs.org> Message-ID: <2afc10d0-4b0f-946f-37cd-4ad6fe9a89a7@linuxia.de> On 12/04/2016 09:13 PM, Peter wrote: > On 04/12/16 22:10, Ren? wrote: >> I found a bug in the Admin-UI that gave an 500 Internal Server Error >> when downloading tables from the Table Manager (admin/gentable). PJ >> suggested to add an Autoload to the catalog_afer.cfg, and this fixed the >> problem. >> >> I created a pull-request @github with a patch. >> >> https://github.com/interchange/interchange/pull/105 > > The AutoLoad is not necessarily what I would recommend for a permanent > fix. The issue is that the ui_download ActionMap makes a call to > $Tag->if_mm, which attempts to open the access table. Because it's > being run in a Safe container it can't do so unless the table is opened > ahead of time, which it isn't for the actionmap. > > The AutoLoad is a bit of a sledgehammer approach because it pre-loads > the access table for every page, not just the ActionMap, but it does > confirm (and fix) the issue. > > Other solutions would be to move the ActionMap to global code, or > rewrite it so that it pre-opens the table itself, possibly by using ITL > with a [perl access] tag instead of a sub. > > > Peter Also I strongly suggest to move this table into SQL instead of using a text database. Regards Racke -- Ecommerce and Linux consulting + Perl and web application programming. Debian and Sympa administration. From peter at pajamian.dhs.org Mon Dec 5 18:35:22 2016 From: peter at pajamian.dhs.org (Peter) Date: Tue, 6 Dec 2016 07:35:22 +1300 Subject: [ic] Bug in the admin-UI In-Reply-To: <2afc10d0-4b0f-946f-37cd-4ad6fe9a89a7@linuxia.de> References: <1e797c05-b858-0bb9-4df0-3bc34eca8f33@pajamian.dhs.org> <2afc10d0-4b0f-946f-37cd-4ad6fe9a89a7@linuxia.de> Message-ID: <5b9746bd-4de6-83f5-a085-4f8fb10e259f@pajamian.dhs.org> On 05/12/16 21:27, Stefan Hornburg (Racke) wrote: > Also I strongly suggest to move this table into SQL instead of using > a text database. I agree with that, but it won't solve the issue here. Peter From David_e at charter.net Mon Dec 5 20:28:30 2016 From: David_e at charter.net (David_e at charter.net) Date: Mon, 5 Dec 2016 14:28:30 -0600 Subject: [ic] export.import on upgrade Message-ID: <93BBC52752DC4AAB8BADBB9D59D5831B@blackbox> We are having a problem upgrading one site the had date exported from ver 4.8.2 importing to 5.10. I think that there was a thread on this a while back but I can not find it. Same problem un userdb and transactions. The main problem is that we are getting a null field error in the customer id field on line 2 of the import. The field has correct data so I am assuming that there is some extra data in the old export that is causing a shift. I see that the file format has changed. Any suggestions? Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at endpoint.com Mon Dec 5 21:26:58 2016 From: david at endpoint.com (David Christensen) Date: Mon, 5 Dec 2016 15:26:58 -0600 Subject: [ic] export.import on upgrade In-Reply-To: <93BBC52752DC4AAB8BADBB9D59D5831B@blackbox> References: <93BBC52752DC4AAB8BADBB9D59D5831B@blackbox> Message-ID: <38D36294-BEB9-40FE-A7DC-9E0663209B33@endpoint.com> > On Dec 5, 2016, at 2:28 PM, David_e at charter.net wrote: > > The main problem is that we are getting a null field error in the customer id field on line 2 of the import. The field has correct data so I am assuming that there is some extra data in the old export that is causing a shift. I see that the file format has changed. Do you have the exact error message? It may be helpful to define the PREFER_NULL attribute in that field?s data declaration; i.e.: Database my_table_name PREFER_NULL field_name HTH, David -- David Christensen End Point Corporation david at endpoint.com 785-727-1171 From noreply at brandsvillage.net Mon Dec 5 22:27:31 2016 From: noreply at brandsvillage.net (Brandsvillage) Date: Mon, 5 Dec 2016 22:27:31 +0000 Subject: [ic] Save uptp 65% off Emporio Armani Half Zip Jumpers Message-ID: An HTML attachment was scrubbed... URL: From interchange at hertell.com Tue Dec 6 00:02:59 2016 From: interchange at hertell.com (=?UTF-8?B?UmVuw6k=?=) Date: Tue, 6 Dec 2016 02:02:59 +0200 Subject: [ic] UTF-8-issue Message-ID: <9a50ccce-c63e-1da4-4caf-210c5dd41ef6@hertell.com> Hi folks! I stumbled into a new Internal Server Error when exporting tables via the admin-ui. I got the following error in the log: admin/export_table Runtime error: Undefined subroutine &Vend::CharSet::is_utf8 called at /usr/local/interchange/lib/Vend/CharSet.pm line 61 This time the reason was a forgotten "export MINIVEND_DISABLE_UTF8=1" in my init-script. Removing that line fixed it. Users upgrading with MINIVEND_DISABLE_UTF8 set will most likely get the same error if not removing this setting.. BR Ren? From peter at pajamian.dhs.org Tue Dec 6 00:22:37 2016 From: peter at pajamian.dhs.org (Peter) Date: Tue, 6 Dec 2016 13:22:37 +1300 Subject: [ic] UTF-8-issue In-Reply-To: <9a50ccce-c63e-1da4-4caf-210c5dd41ef6@hertell.com> References: <9a50ccce-c63e-1da4-4caf-210c5dd41ef6@hertell.com> Message-ID: <5ec1df12-1474-9e59-81e2-358a5bd5008b@pajamian.dhs.org> On 06/12/16 13:02, Ren? wrote: > Hi folks! > > I stumbled into a new Internal Server Error when exporting tables via > the admin-ui. I got the following error in the log: > > admin/export_table Runtime error: Undefined subroutine > &Vend::CharSet::is_utf8 called at > /usr/local/interchange/lib/Vend/CharSet.pm line 61 > > This time the reason was a forgotten "export MINIVEND_DISABLE_UTF8=1" in > my init-script. Removing that line fixed it. Users upgrading with > MINIVEND_DISABLE_UTF8 set will most likely get the same error if not > removing this setting.. More to the point is_utf8 is explicitly not exported to Vend::CharSet if MINIVEND_DISABLE_UTF8 is set, which suggests that in this case export_table should not be attempting to call is_utf8. I think we may run across this on occasion and as such it might make sense to put in a stub is_utf8 function that always returns false when MINIVEND_DISABLE_UTF8 is set. Peter From david at endpoint.com Tue Dec 6 15:50:38 2016 From: david at endpoint.com (David Christensen) Date: Tue, 6 Dec 2016 09:50:38 -0600 Subject: [ic] UTF-8-issue In-Reply-To: <5ec1df12-1474-9e59-81e2-358a5bd5008b@pajamian.dhs.org> References: <9a50ccce-c63e-1da4-4caf-210c5dd41ef6@hertell.com> <5ec1df12-1474-9e59-81e2-358a5bd5008b@pajamian.dhs.org> Message-ID: <4090535A-2F78-4321-AF7B-8C3939572DAB@endpoint.com> > On Dec 5, 2016, at 6:22 PM, Peter wrote: > > On 06/12/16 13:02, Ren? wrote: >> Hi folks! >> >> I stumbled into a new Internal Server Error when exporting tables via >> the admin-ui. I got the following error in the log: >> >> admin/export_table Runtime error: Undefined subroutine >> &Vend::CharSet::is_utf8 called at >> /usr/local/interchange/lib/Vend/CharSet.pm line 61 >> >> This time the reason was a forgotten "export MINIVEND_DISABLE_UTF8=1" in >> my init-script. Removing that line fixed it. Users upgrading with >> MINIVEND_DISABLE_UTF8 set will most likely get the same error if not >> removing this setting.. > > More to the point is_utf8 is explicitly not exported to Vend::CharSet if > MINIVEND_DISABLE_UTF8 is set, which suggests that in this case > export_table should not be attempting to call is_utf8. > > I think we may run across this on occasion and as such it might make > sense to put in a stub is_utf8 function that always returns false when > MINIVEND_DISABLE_UTF8 is set. Which IC version are you using? I?d found and fixed a few issues with this recently, so if you?re using 5.10 and not HEAD you might consider upgrading. Otherwise, I may have missed some spots. David -- David Christensen End Point Corporation david at endpoint.com 785-727-1171 From David_e at charter.net Tue Dec 6 18:42:27 2016 From: David_e at charter.net (David_e at charter.net) Date: Tue, 6 Dec 2016 12:42:27 -0600 Subject: [ic] export.import on upgrade References: <93BBC52752DC4AAB8BADBB9D59D5831B@blackbox> <38D36294-BEB9-40FE-A7DC-9E0663209B33@endpoint.com> Message-ID: <1425DAF2F3634F7FAD862C96BC866EFF@blackbox> Might not be a good thing to define the user ID or the order number as a NULL. This would not fix the problem if the fields are out of line. The data imported would just be garbage. David > On Dec 5, 2016, at 2:28 PM, David_e at charter.net wrote: > > The main problem is that we are getting a null field error in the customer > id field on line 2 of the import. The field has correct data so I am > assuming that there is some extra data in the old export that is causing a > shift. I see that the file format has changed. Do you have the exact error message? It may be helpful to define the PREFER_NULL attribute in that field?s data declaration; i.e.: Database my_table_name PREFER_NULL field_name HTH, David -- David Christensen End Point Corporation david at endpoint.com 785-727-1171 From interchange at hertell.com Wed Dec 7 11:20:46 2016 From: interchange at hertell.com (=?UTF-8?B?UmVuw6k=?=) Date: Wed, 7 Dec 2016 13:20:46 +0200 Subject: [ic] UTF-8-issue In-Reply-To: <4090535A-2F78-4321-AF7B-8C3939572DAB@endpoint.com> References: <9a50ccce-c63e-1da4-4caf-210c5dd41ef6@hertell.com> <5ec1df12-1474-9e59-81e2-358a5bd5008b@pajamian.dhs.org> <4090535A-2F78-4321-AF7B-8C3939572DAB@endpoint.com> Message-ID: On 06.12.2016 17:50, David Christensen wrote: > Which IC version are you using? I?d found and fixed a few issues > with this recently, so if you?re using 5.10 and not HEAD you might > consider upgrading. Otherwise, I may have missed some spots. Hi, It's the latest git-version from github. BR Ren? From david at endpoint.com Wed Dec 7 17:40:13 2016 From: david at endpoint.com (David Christensen) Date: Wed, 7 Dec 2016 11:40:13 -0600 Subject: [ic] UTF-8-issue In-Reply-To: References: <9a50ccce-c63e-1da4-4caf-210c5dd41ef6@hertell.com> <5ec1df12-1474-9e59-81e2-358a5bd5008b@pajamian.dhs.org> <4090535A-2F78-4321-AF7B-8C3939572DAB@endpoint.com> Message-ID: > On Dec 7, 2016, at 5:20 AM, Ren? wrote: > > On 06.12.2016 17:50, David Christensen wrote: > >> Which IC version are you using? I?d found and fixed a few issues >> with this recently, so if you?re using 5.10 and not HEAD you might >> consider upgrading. Otherwise, I may have missed some spots. > > Hi, > > It's the latest git-version from github. Hi Ren?, I?ve pushed a patch which makes sure stub routines are installed when MINIVEND_DISABLE_UTF8 is set. Let me know if this resolves your issues. Regards, David -- David Christensen End Point Corporation david at endpoint.com 785-727-1171 From scaballe at gmail.com Wed Dec 14 09:33:07 2016 From: scaballe at gmail.com (S. Caballe) Date: Wed, 14 Dec 2016 10:33:07 +0100 Subject: [ic] Google reCAPTCHA v2 Message-ID: Hello, Someone included Captcha::reCAPTCHA::V2. (usertag) in the Interchange forms ?? Salvador Caball? From jon at endpoint.com Fri Dec 23 04:39:49 2016 From: jon at endpoint.com (Jon Jensen) Date: Thu, 22 Dec 2016 21:39:49 -0700 (MST) Subject: [ic] A few minor UserDB patch proposals Message-ID: Everyone, I'd like to propose a few minor patches to UserDB. The first one is at login time, to set $Vend::admin earlier so that its value is accessible to the optional postlogin_action: https://github.com/jonjensen/interchange/commit/e250c1f2701eec05f1e6f6c68af919e12af1d63c >From what I can see that should not have any ill effect, or any other effect at all, really, since nothing else happens in the interim. The second one is to add a prelogout_action akin to the postlogin_action and allow arbitrary code to be hooked into the logout function: https://github.com/jonjensen/interchange/commit/02467791bf3ed83551ca9daf919f81115373b296 Any objections or comments? Thanks, Jon -- Jon Jensen End Point Corporation https://www.endpoint.com/ From racke at linuxia.de Fri Dec 23 10:15:07 2016 From: racke at linuxia.de (Stefan Hornburg (Racke)) Date: Fri, 23 Dec 2016 11:15:07 +0100 Subject: [ic] A few minor UserDB patch proposals In-Reply-To: References: Message-ID: <8db3bdfb-81d1-3900-ca10-6ed3dec355b1@linuxia.de> On 12/23/2016 05:39 AM, Jon Jensen wrote: > Everyone, > > I'd like to propose a few minor patches to UserDB. > > The first one is at login time, to set $Vend::admin earlier so that its > value is accessible to the optional postlogin_action: > > https://github.com/jonjensen/interchange/commit/e250c1f2701eec05f1e6f6c68af919e12af1d63c > > > From what I can see that should not have any ill effect, or any other > effect at all, really, since nothing else happens in the interim. > > The second one is to add a prelogout_action akin to the postlogin_action > and allow arbitrary code to be hooked into the logout function: > > https://github.com/jonjensen/interchange/commit/02467791bf3ed83551ca9daf919f81115373b296 > > > Any objections or comments? > > Thanks, > Jon > > Sounds good to me ... +1 Regards Racke -- Ecommerce and Linux consulting + Perl and web application programming. Debian and Sympa administration. From gert at 3edge.com Fri Dec 23 12:30:30 2016 From: gert at 3edge.com (Gert van der Spoel) Date: Fri, 23 Dec 2016 14:30:30 +0200 Subject: [ic] A few minor UserDB patch proposals In-Reply-To: <8db3bdfb-81d1-3900-ca10-6ed3dec355b1@linuxia.de> References: <8db3bdfb-81d1-3900-ca10-6ed3dec355b1@linuxia.de> Message-ID: <009101d25d18$59f14cb0$0dd3e610$@3edge.com> > On 12/23/2016 05:39 AM, Jon Jensen wrote: > > Everyone, > > > > I'd like to propose a few minor patches to UserDB. > > > > The first one is at login time, to set $Vend::admin earlier so that > > its value is accessible to the optional postlogin_action: > > > > > https://github.com/jonjensen/interchange/commit/e250c1f2701eec05f1e6f6 > > c68af919e12af1d63c > > > > > > From what I can see that should not have any ill effect, or any other > > effect at all, really, since nothing else happens in the interim. > > > > The second one is to add a prelogout_action akin to the > > postlogin_action and allow arbitrary code to be hooked into the logout > function: > > > > > https://github.com/jonjensen/interchange/commit/02467791bf3ed83551ca9d > > af919f81115373b296 > > > > > > Any objections or comments? > > > > Thanks, > > Jon > > > > > > Sounds good to me ... +1 > > Regards > Racke +1 & Happy holidays :) From jlavin at endpoint.com Fri Dec 23 16:28:41 2016 From: jlavin at endpoint.com (Josh Lavin) Date: Fri, 23 Dec 2016 08:28:41 -0800 Subject: [ic] Proposed Route patch Message-ID: <20161223162841.GG26028@desmond.localdomain> It seems that the long-standing comment about the 'main' Route in catalog.cfg is wrong: ## This route emails the order to you unless email is set to "", and ## failsafe-logs the order report a couple of places If you follow those instructions, then you see an error: > Empty order routing main_entry (and not explicitly empty). > Either attach or email are required in the route setting. Kevin's docs are correct in this area: "Note that either attach, email or empty must be set for a route." http://interchange.rtfm.info/icdocs/Order_routing.html#email If you blank out 'email', but also set either 'attach' or 'empty' to 1, then customer orders never show a receipt page, nor clear the cart, yet an order is accepted. I followed the rabbit, and this ocurrs as $status is returned by route_order() and is necessary to show the receipt and clear the cart. Yet, $status is only set if emails are sent. The following patch fixes it, and corrects the documentation: https://github.com/jdigory/interchange/commit/928a93b11c8862f38f201c0d1fdfb94d777cee69 Does anyone know if setting $status to true when no emails are sent is a problem? Routing is an odd beast, but this seems to work fine in my tests. Thanks, Josh -- Josh Lavin End Point Corporation From mike at heins.com Fri Dec 23 20:28:42 2016 From: mike at heins.com (Mike Heins) Date: Fri, 23 Dec 2016 15:28:42 -0500 Subject: [ic] Proposed Route patch In-Reply-To: <20161223162841.GG26028@desmond.localdomain> References: <20161223162841.GG26028@desmond.localdomain> Message-ID: I'd have to look. This is a funny beast -- it is some of the first code in Interchange and indeed is brought from the very earliest vend.pl code in 1995. My worry is that there is a tri-sense for $status. True, false, and undef. Have you looked at how it is used in the "submit" action in Vend::Dispatch? On Fri, Dec 23, 2016 at 11:28 AM, Josh Lavin wrote: > It seems that the long-standing comment about the 'main' Route in > catalog.cfg is wrong: > > ## This route emails the order to you unless email is set to "", and > ## failsafe-logs the order report a couple of places > > If you follow those instructions, then you see an error: > > > Empty order routing main_entry (and not explicitly empty). > > Either attach or email are required in the route setting. > > Kevin's docs are correct in this area: > "Note that either attach, email or empty must be set for a route." > http://interchange.rtfm.info/icdocs/Order_routing.html#email > > If you blank out 'email', but also set either 'attach' or 'empty' to 1, > then customer orders never show a receipt page, nor clear the cart, yet > an order is accepted. > > I followed the rabbit, and this ocurrs as $status is returned by > route_order() and is necessary to show the receipt and clear the cart. > Yet, $status is only set if emails are sent. > > The following patch fixes it, and corrects the documentation: > > https://github.com/jdigory/interchange/commit/ > 928a93b11c8862f38f201c0d1fdfb94d777cee69 > > Does anyone know if setting $status to true when no emails are sent is a > problem? Routing is an odd beast, but this seems to work fine in my > tests. > > Thanks, > Josh > -- > Josh Lavin > End Point Corporation > > _______________________________________________ > interchange-users mailing list > interchange-users at icdevgroup.org > http://www.icdevgroup.org/mailman/listinfo/interchange-users > -- The problem with Internet quotations is that many of them are not genuine. -- Abraham Lincoln -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlavin at endpoint.com Fri Dec 23 23:04:44 2016 From: jlavin at endpoint.com (Josh Lavin) Date: Fri, 23 Dec 2016 15:04:44 -0800 Subject: [ic] Proposed Route patch In-Reply-To: References: <20161223162841.GG26028@desmond.localdomain> Message-ID: <20161223230444.GK26028@desmond.localdomain> Quoting Mike Heins (mike at heins.com): > I'd have to look. This is a funny beast -- it is some of the first code in > Interchange and indeed is brought from the very earliest vend.pl code in > 1995. My worry is that there is a tri-sense for $status. True, false, and > undef. Have you looked at how it is used in the "submit" action in > Vend::Dispatch? Well, in Vend::Dispatch, it is "$ok" (line 476): ($ok, $order_no, $result_hash) = route_order( $::Values->{mv_order_route}, $Vend::Items ); return 1 unless $ok; In Vend::Order, the route_order() sub returns: if($main->{supplant}) { return ($status, $::Values->{mv_order_number}, $main); } So it is $status in Vend::Order, but $ok in Vend::Dispatch. The problem in Vend::Dispatch is that if $ok isn't set, it won't finish the order, at least to the customer's point of view. Thanks, Josh > On Fri, Dec 23, 2016 at 11:28 AM, Josh Lavin wrote: > > > It seems that the long-standing comment about the 'main' Route in > > catalog.cfg is wrong: > > > > ## This route emails the order to you unless email is set to "", and > > ## failsafe-logs the order report a couple of places > > > > If you follow those instructions, then you see an error: > > > > > Empty order routing main_entry (and not explicitly empty). > > > Either attach or email are required in the route setting. > > > > Kevin's docs are correct in this area: > > "Note that either attach, email or empty must be set for a route." > > http://interchange.rtfm.info/icdocs/Order_routing.html#email > > > > If you blank out 'email', but also set either 'attach' or 'empty' to 1, > > then customer orders never show a receipt page, nor clear the cart, yet > > an order is accepted. > > > > I followed the rabbit, and this ocurrs as $status is returned by > > route_order() and is necessary to show the receipt and clear the cart. > > Yet, $status is only set if emails are sent. > > > > The following patch fixes it, and corrects the documentation: > > > > https://github.com/jdigory/interchange/commit/ > > 928a93b11c8862f38f201c0d1fdfb94d777cee69 > > > > Does anyone know if setting $status to true when no emails are sent is a > > problem? Routing is an odd beast, but this seems to work fine in my > > tests. > > > > Thanks, > > Josh > > -- > > Josh Lavin > > End Point Corporation > > > > _______________________________________________ > > interchange-users mailing list > > interchange-users at icdevgroup.org > > http://www.icdevgroup.org/mailman/listinfo/interchange-users > > > > > > -- > The problem with Internet quotations is that many of them > are not genuine. -- Abraham Lincoln > _______________________________________________ > interchange-users mailing list > interchange-users at icdevgroup.org > http://www.icdevgroup.org/mailman/listinfo/interchange-users -- Josh Lavin End Point Corporation From jon at endpoint.com Sat Dec 24 15:04:34 2016 From: jon at endpoint.com (Jon Jensen) Date: Sat, 24 Dec 2016 08:04:34 -0700 (MST) Subject: [ic] A few minor UserDB patch proposals In-Reply-To: <009101d25d18$59f14cb0$0dd3e610$@3edge.com> References: <8db3bdfb-81d1-3900-ca10-6ed3dec355b1@linuxia.de> <009101d25d18$59f14cb0$0dd3e610$@3edge.com> Message-ID: On Fri, 23 Dec 2016, Gert van der Spoel wrote: >>> I'd like to propose a few minor patches to UserDB. >> >> Sounds good to me ... +1 > > +1 & Happy holidays :) Thanks for the input, Racke & Gert. Merry Christmas and happy holidays to you all too! Jon -- Jon Jensen End Point Corporation https://www.endpoint.com/ From wbetzjr at pennherb.com Sun Dec 25 04:36:16 2016 From: wbetzjr at pennherb.com (William P. Betz Jr.) Date: Sat, 24 Dec 2016 23:36:16 -0500 Subject: [ic] Admin - Display only field Message-ID: <39895aa0-7205-cff2-1ef5-c3299943879a@pennherb.com> Hello Everyone: Just wondering if there is a way in IC Admin (perhaps editing a field's meta data?) to set it as a display only field (no input allowed)? I import new records into the products table using: [import-fields table=products file=upload/newrecords.update add=1 move=1 dir=backup] [export table=products hide=1] There is one static field I do not want anyone to change - ever - and right now it is editable in IC admin -> Items. Thanks. -- Best regards, Bill Betz From m.mescoli at omnib.it Sun Dec 25 06:42:32 2016 From: m.mescoli at omnib.it (marco) Date: Sun, 25 Dec 2016 07:42:32 +0100 Subject: [ic] My best wishes to the list :-) from Italy In-Reply-To: <009101d25d18$59f14cb0$0dd3e610$@3edge.com> References: <8db3bdfb-81d1-3900-ca10-6ed3dec355b1@linuxia.de> <009101d25d18$59f14cb0$0dd3e610$@3edge.com> Message-ID: <585F6A58.5080700@omnib.it> -- "Fino alla bara sinpara" "Up to demise we rize" From gert at 3edge.com Sun Dec 25 07:55:24 2016 From: gert at 3edge.com (Gert van der Spoel) Date: Sun, 25 Dec 2016 09:55:24 +0200 Subject: [ic] My best wishes to the list :-) from Italy In-Reply-To: <585F6A58.5080700@omnib.it> References: <8db3bdfb-81d1-3900-ca10-6ed3dec355b1@linuxia.de> <009101d25d18$59f14cb0$0dd3e610$@3edge.com> <585F6A58.5080700@omnib.it> Message-ID: <00af01d25e84$401508a0$c03f19e0$@3edge.com> > Subject: [ic] My best wishes to the list :-) from Italy > > -- > "Fino alla bara sinpara" > "Up to demise we rize" > And the same to you! :) From peter at pajamian.dhs.org Sun Dec 25 23:48:57 2016 From: peter at pajamian.dhs.org (Peter) Date: Mon, 26 Dec 2016 12:48:57 +1300 Subject: [ic] Admin - Display only field In-Reply-To: <39895aa0-7205-cff2-1ef5-c3299943879a@pennherb.com> References: <39895aa0-7205-cff2-1ef5-c3299943879a@pennherb.com> Message-ID: <6b6da49f-20d6-0f9d-9703-618f7dbc3e8a@pajamian.dhs.org> On 25/12/16 17:36, William P. Betz Jr. wrote: > Hello Everyone: > > Just wondering if there is a way in IC Admin (perhaps editing a field's > meta data?) to set it as a display only field (no input allowed)? If you edit the field's metadata you can change the widget type to "hiddentext". It is not in the drop down, so you must enter it manually in the text field next to the drop down list. Peter From wbetzjr at pennherb.com Mon Dec 26 13:48:51 2016 From: wbetzjr at pennherb.com (William P. Betz Jr.) Date: Mon, 26 Dec 2016 08:48:51 -0500 Subject: [ic] Admin - Display only field In-Reply-To: References: Message-ID: > On 25/12/16 17:36, William P. Betz Jr. wrote: >> Hello Everyone: >> >> Just wondering if there is a way in IC Admin (perhaps editing a field's >> meta data?) to set it as a display only field (no input allowed)? > If you edit the field's metadata you can change the widget type to > "hiddentext". It is not in the drop down, so you must enter it manually > in the text field next to the drop down list. > > > Peter Thanks, Peter! That did the trick. Bill