Hi,
after an svn update to 1.6.003 just half an hour ago to rev 29311 I get the
following error message in the logs:
PHP Fatal error: Call to undefined method infolog_ical::calc_dtstart() in
/raid/www/htdocs/egroupware/calendar/inc/class.calendar_ical.inc.php on line
2975
and kontact says it can't read the calendar.
What can be done?
Christoph

SVN trunk
Logged in as Admin
Resources App
cannot add resounces
loot at a calendar or the resource
Access denied to the calendar of Meeting room 2 !!!
goto Calendar App
Access denied to the calendar of Meeting room 2 !!!
no calendar any more
no way to change it
uninstalled App
deleted resources databases
installed App
same thing.

On Mon, Feb 22, 2010 at 8:47 PM, WLD <ml-egwperp@...> wrote:
> It's in the pERP sales order screen when adding a line item to a new order, the AJAX select box shows the results when searching for a stock code, but doesn't allow me to select a line. When I click on a result, the result box simply disappears, and the line isn't pre-filled.
This sounds like a problem with perp_orders, rather than the AJAX
widget, because you do get results. The multi-key should be handled
all on the PHP side, and just returned and passed on. This indicates
the problem lies somewhere from the action handler forward. When you
select a result from the list, it should call the js function
select_item().
>...At what point was the AJAX selection widget modified to allow multiple ID's to be returned? This may help me identify if I have copied any old files in to my setup by mistake.
Mon Sep 21 18:34:14 2009 UTC (5 months ago)
http://svn.stylite.de/viewvc/egroupware?view=rev&revision=27890
No javascript changes for that though.
You may be experiencing problems with a recent commit that helped the
AJAX widget work around IE 8.
Mon Feb 15 20:40:34 2010 UTC (7 days, 8 hours ago)
http://svn.stylite.de/viewvc/egroupware?view=rev&revision=29242
Nathan

Although I spout the benefits of virtualisation often, it has this evening lead me in to trouble. A bug has been introduced in to a working copy of a setup and I cannot understand how something that was working has managed to become broken, or even when it has become broken.
It's in the pERP sales order screen when adding a line item to a new order, the AJAX select box shows the results when searching for a stock code, but doesn't allow me to select a line. When I click on a result, the result box simply disappears, and the line isn't pre-filled.
From preliminary investigation I believe that the AJAX search widget javascript file has been replaced with an older version that didn't support multiple keys being returned. In the etemplate, the widget is requesting the ID's stock_id;price_list_id from perp_orders.bo_perp_price.get_merged_price_list. If I change it to request just one of the ID's, it works fine. The javascript process works fine and the line is pre-filled (although with a missing field).
When using the latest /etemplate/inc/class.ajax_select_widget.inc.php from the trunk it *does* work when requesting *both* ID's. When using the version in my VM as it stands it doesn't work when requesting *both* ID's.
The possibilities are that I have inadvertently replaced this javascript file with an old version which doesn't work with multiple IDs; or there is some other bug or misconfiguration going on here. At what point was the AJAX selection widget modified to allow multiple ID's to be returned? This may help me identify if I have copied any old files in to my setup by mistake.
Alternatively do you have any other theories on why the add line AJAX widget isn't allowing me to choose a stock item which is in a valid price list for the client?
I have compared my perp_orders.sales_order_edit etemplate with the version on the pERP demo site and it's identical. The only thing that seems to have changed is the javascript file version seems out of step with the rest of the eGW API 1.7.003 or I have a simple config error.
Kindest thanks in anticipation of suggestions,
Paul

On Fri, Feb 12, 2010 at 8:04 AM, Jazbin <vannovak@...> wrote:
>
> Hello!
>
> I'm having trouble uploading an image to the server
> ...
> When I'm calling the $this->save_picture($content['slika'],$id); the picture
> does not show in FileManager in /apps/app/$id/ folder. Folder doesn't even
> exist. I took this code for saving and retrieving images from eGW Resources
> application but I can't get it to work on my app. Do I have to have some
> special rights to upload an image or file? Are there any preconditions that
Sorry I don't know much about uploading images, but depending on what
you need to do, just using the LinkTo widget might work. It handles
the backend on its own. Otherwise, you might look at
/etemplate/inc/class.link_widget.inc.php around Line 556 to see how
the link widget does it.
Nathan

On Wednesday 17 Feb 2010 02:45:58 Nathan Gray wrote:
> You're best using the API over modifying the database directly,
> because then things like history can be updated.
> I think you might have to deal with egw_api_content_history.
That was my original intention for all my import processes. However getting access to just the eGW API without it moaning, and without having to write an application for eGW, was a lot more trouble than it was worth :) I simply tailed the SQL query log to discover what was actually being modified, and went from there. I know it's a bit naughty but really I was surprised how hard interfacing with the API is when all you need a quick dirty hack finished in 20 minutes :-O But don't forget I have a commercial consideration and can't justify spending a day perfecting what could be done in a dirty 20 minute hack. Although I have to say, running eGW+pERP in a virtual machine made this process of trial-and-error much easier, as I could instantly roll-back changes to multiple tables in just a few moments and try again until it worked, safe in the knowledge I wasn't repeatedly causing compounding damage.
All my import processes update the eGW+pERP tables with vast amounts of data from various legacy systems, and also there's the consideration that it's not resource efficient to run through the API without it taking twice as long. The total import process as it stands for my latest client can take around 2.5 hours and that's not even including the conversion compromises that were made with historical data there's no value in importing. Additionally you have to bare in mind that it's a large assumption to make that the legacy systems even support running eGW+pERP. And also you have to bare in mind that often different business processes are usually split over different applications, and different servers. You can't keep moving the eGW+pERP installation around each system and pull data in bit by bit (again assuming that can even be done on each of the legacy systems). The import scripts are typically programmed in whatever language is suitable on the particular legacy system containing particular data, and it sends this data in a raw format to the import server which glues it all back together and does the actual writing it to the database. This is the most practical way to achieve the end goal that covers nearly all the myriad of existing systems out there.
Regarding our recent posts on the progress being made with pERP, please recall that I mentioned to Justin that one of the requirements for pERP to enter the mainstream is a migration path. You can't upgrade a client and just hand over an empty system and tell them to enter everything by hand. For the intervention to succeed, the new system has to have all the latest data, and as much historical data as is decided to be of use.
I think we may all have to begrudgingly get used to the fact that the entire subject of migrating from various systems out there to eGW+pERP is always going to be a dirty job that's only perfected until it seems to the programmer as if it's working ok. I know it's not ideal, but the key consideration is "does it work?!" and not "is it perfect?!" :)
Still, I'm trying to be mindful if I've overlooked the same this as the OP here and if you have any other pointers they will be most gratefully received. I am updating egw_api_content_history fortunately.
Kindest thanks,
Paul

On Tue, Feb 16, 2010 at 9:31 AM, K-Duke <kb@...> wrote:
>
>...
> Might someone of you know which other tables than egw_addressbook are
> affected by a phone sync (using funambol and vCard-Option).
You're best using the API over modifying the database directly,
because then things like history can be updated.
I think you might have to deal with egw_api_content_history.

On Tuesday 16 Feb 2010 16:31:11 K-Duke wrote:
>
> I have written an contacts import-script which takes a csv-file from the
> webDav-directory and then imports them into the egw_addressbook table.
> Though I've got the problem if a contact is updated by this script a phone
> sync won't update this contact while it works flawlessly if modified from
> within egw. So I guess I'm missing a timestamp or another flag which has to
> be set correctly so the phone know which contacts have been updated.
> Might someone of you know which other tables than egw_addressbook are
> affected by a phone sync (using funambol and vCard-Option).
> I already digged into the database using several methods like creating diffs
> of several database-states and browsing through table descriptions though I
> can't seem to find which value has to be set/inserted for it to work.
>
> greetings
I've also created import scripts to populate addressbook data and would be similarly keen to discover if my scripts are also susceptible to this issue, and the causes behind it. Please keep me updated if you discover what it is!
Kindest regards,
Paul

I have written an contacts import-script which takes a csv-file from the
webDav-directory and then imports them into the egw_addressbook table.
Though I've got the problem if a contact is updated by this script a phone
sync won't update this contact while it works flawlessly if modified from
within egw. So I guess I'm missing a timestamp or another flag which has to
be set correctly so the phone know which contacts have been updated.
Might someone of you know which other tables than egw_addressbook are
affected by a phone sync (using funambol and vCard-Option).
I already digged into the database using several methods like creating diffs
of several database-states and browsing through table descriptions though I
can't seem to find which value has to be set/inserted for it to work.
greetings
--
View this message in context: http://old.nabble.com/Affected-database-tables-for-phone-sync-tp27611026s3741p27611026.html
Sent from the egroupware-developers mailing list archive at Nabble.com.

Hello!
I'm having trouble uploading an image to the server using simple functions
and a simple template containing only FileUpload type named slika.
I didn't find any simple examples on the forum.
These are my functions that I'm using to save and get my images:
function save_picture($file,$resouce_id)
{
egw_link::attach_file('app',$resouce_id,array(
'tmp_name' => $file['tmp_name'],
'name' => self::PICTURE_NAME,
'type' => 'image/jpeg',
));
}
function get_picture($res_id=0,$fullsize=false)
{
$picture = egw_link::vfs_path('app',$res_id,self::PICTURE_NAME,true); //
vfs path
if ($fullsize)
{
$picture = egw::link(egw_vfs::download_url($picture));
}
else
{
$picture = egw::link('/etemplate/thumbnail.php',array('path' =>
$picture));
}
return $picture;
}
When I'm calling the $this->save_picture($content['slika'],$id); the picture
does not show in FileManager in /apps/app/$id/ folder. Folder doesn't even
exist. I took this code for saving and retrieving images from eGW Resources
application but I can't get it to work on my app. Do I have to have some
special rights to upload an image or file? Are there any preconditions that
I have to do to enable file uploading?
Thank You.
--
View this message in context: http://old.nabble.com/Simple-picture-upload-tp27564882s3741p27564882.html
Sent from the egroupware-developers mailing list archive at Nabble.com.

I "fixed" a problem in our installation (1.6.001) with eGWOSync not being
able to log-in to anything other then the default domain.
The problem is that $GLOBALS['egw_info']['user']['domain'] is being set in
functions.inc.php based on values which are not set when the client connects
via xmlrpc (see below).
I changed xml_functions.inc.php as follows to get us going:
***************
*** 783,788 ****
--- 783,789 ----
if($data['domain'])
{
$domain = $data['domain']->scalarval();
+ $GLOBALS['egw_info']['user']['domain'] = $domain;
}
$username = $data['username']->scalarval();
$password = $data['password']->scalarval();
Am I missing something or is this a bug?
Any suggestions on a recommended workaround if it is a bug?
Here's the line that sets up the $GLOBALS['egw_info']['user']['domain']:
$GLOBALS['egw_info']['user']['domain'] = egw_session::search_instance(
isset($_POST['login']) ? $_POST['login'] :
(isset($_SERVER['PHP_AUTH_USER']) ? $_SERVER['PHP_AUTH_USER'] :
$_SERVER['REMOTE_USER']),
--
View this message in context: http://old.nabble.com/xmlrpc---multiple-domains-tp27555896s3741p27555896.html
Sent from the egroupware-developers mailing list archive at Nabble.com.

funny thing, where did you read that?
As far as I know, a refresh of the screen is only triggered by the email
module.
There is the refreshinterval for tracker mailhandling, but that is an
entirely different issue
and does not include tracker list refresh on the browser side, as it is run
as async job.
----------------ursprüngliche Nachricht-----------------
Von: "NickJ" nick.ward@...
An: egroupware-developers@... Datum: Wed, 10 Feb 2010
09:05:45 -0800 (PST)
-------------------------------------------------
>
> Hi,
> I read in the documentation that you can set a time for refreshing the
> screen in the TRacker Queue but I can't seem to find where to alter this
> setting.
>
> Could somebody please point me in the right direction.
>
> Thanks
>
> Nick
> --
> View this message in context:
> http://old.nabble.com/Tracking-system--Screen-not-refreshing-tp27534
> 450s3741p27534450.html
> Sent from the egroupware-developers mailing list archive at Nabble.com.
>
>
>
> --------------------------------------------------------------------
> ----------
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev
> _______________________________________________
> eGroupWare-developers mailing list
> eGroupWare-developers@...
https://lists.sourceforge.net/lists/listinfo/egroupware-developers
>
--
Stylite GmbH
[ open style of IT ]
Morschheimer Strasse 15
67292 Kirchheimbolanden
fon 06352 . 70629-0
fax 06352 . 70629-30
http://www.stylite.de
Geschäftsführer: Andre Keller, Gudrun Müller, Ralf Becker
Handelsregister Kaiserslautern HRB 30575
USt-ID: DE214280951

Hello all,
I'm coding a module for egroupware atm and have a problem with upload
function.
This is the form i submit a type=file:
echo "<form enctype='multipart/form-data'
action='".$GLOBALS['egw']->link('/index.php',array('menuaction' =>
'etube.uietube.video_upload','message'=>'YES'))."' method='post'> ";
But in my function etube.uietube.video_upload, I have no $_POST and no
$_FILES.
If I remove the enctype I have access to $_POST but the file will not be
uploaded.
Have anybody a hint for me whats wrong?
Is there a code snipped I can have a look?
Thanks in advance
TDOe
--
View this message in context: http://old.nabble.com/upload-problem---enctype-multipart-tp27540736s3741p27540736.html
Sent from the egroupware-developers mailing list archive at Nabble.com.