Menu
▾
▴
outreach-devel — Disscussion of development issues for OPT
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(10) |
Nov
|
Dec
(3) |
|
From: Martin V. <mar...@ti...> - 2004-12-23 18:25:52
|
Hi Grant, no problem, Open Source is, among other things, all a matter of available (spare) time. Thanks anyway for agreeing with the "roadmap". I know for sure it won't be a quickie, because I just started on a new full time assignment, which will take a lot of my energy. 1st Merry X-mas, Happy new year and a bug-fix release ;-) Cheers, Martin. P.S. I suggest we share our thoughts and opinions with regards to OPT on the list, so I cc'd this to the devlist ... >-----Original Message----- >From: Grant Ballard-Tremeer >Sent: donderdag 23 december 2004 17:14 >To: Martin Vernooij >Subject: Re: [Outreach-devel] Preparing for the 1.2.6 release and .... > > >Dear Martin, > >Just a note to say that I'm still alive and kicking, interested, and >wishing I could lend you more support. The end of year has proved >crazily busy - even more than I thought - so I haven't been able to do >any programming whatsoever. > >In any case I looked through your development roadmap and fully agree. >I like the idea of using PEAR for authentication and database >abstraction - it makes absolute sense to me. > >Anyway, I am trying my best to rearrange things so that I have more >time for the things I enjoy (programming) and have to spend less on >the things I don't (admin), but it is proving harder than envisioned >to find the right staff and arrangements. > >Merry Christmas and a Happy New Year! > >Regards >Grant > >Friday, December 17, 2004, 11:45:50 AM, you wrote: > >MV> Team, > >MV> I believe I've fixed the majority of the bugs to get to a >stable 1.2.6 >MV> version. There are couple of things left, but these are >not so easy to >MV> fix. They either relate to the session management/authentication or >MV> multilanguage issues/quoting. The only thing I still want >to do before >MV> freezing this 1.2.6, is to add the three missing pieces of code as >MV> reported in bug report 1078789. > > > |
|
From: Guy D. <da...@gu...> - 2004-12-22 19:32:29
|
Martin Vernooij wrote: > 1. Release 1.2.6 (Guy: Can you show me your scripts how you did/do > this?) Martin, I've attached the Python script I wrote to automate the majority of an OPT release. It requires a basic Linux setup with the addition of the cvs2cl.pl script which is available on the web. Also, it needs password-less accesss via SSH to the SF CVS repository. Depending on your server, you'll also want to get the contents of my http://www.guydavis.ca/opt_releases/ directory. When you are ready, I'll redirect hits from existing OPT installs to my upgrades.xml to your site. You'll need to change anything that was setup for me and my server specifically. Let me know if you have any problems with it. Good luck with the release. Guy |
|
From: Martin V. <mar...@ti...> - 2004-12-17 11:46:03
|
Team, I believe I've fixed the majority of the bugs to get to a stable 1.2.6 version. There are couple of things left, but these are not so easy to fix. They either relate to the session management/authentication or multilanguage issues/quoting. The only thing I still want to do before freezing this 1.2.6, is to add the three missing pieces of code as reported in bug report 1078789. I have the opinion that we should release a 1.2.6 bug fix version now and start working on a 2.0 version. OOPS, did I say 2.0? Yes, I'm afraid so. OPT has come a great way towards a nice and useful package. But development started years ago and many contributions were added since. I did notice not all contributions used the same coding guidelines (were there any?) and as a result the OPT code and database is a mixture of flavors, making it hard to maintain and more important to extend. So my thoughts are going into the following direction: 1. Release 1.2.6 (Guy: Can you show me your scripts how you did/do this?) 2. Re-evaluate the tables and normalise/extend them 3. Implement new authentication / session management based on the PEAR::Auth library (pear.php.net) and db_esession (to be found on: www.phpclasses.org). 4. Implement a database abstraction layer using PEAR::DB 5. Code cleaning and standardisation 6. Implement templating and removing the frame gui by using one of the PEAR:HTML template packages Doing 3 will most likely (understatement) make OPT run more stable. It will also solve a lot of "vague" bug reports which indicate errors not easy to reproduce. It will remove the register_globals requirement, as all specific settings used during a sessions will be handled by the new session management. It will also give a transparant authentication mechanism to authenticate against: * All databases supported by the PEAR database layer * All databases supported by the MDB database layer * All databases supported by the MDB2 database layer * Plaintext files * LDAP servers * POP3 servers * IMAP servers * vpopmail accounts * RADIUS * SAMBA password files * SOAP Doing 4 will solve the other 50% of the outstanding bugs, related to quoting. AND it will bring OPT to run on other databases: currently supported are dbase, fbsql, interbase, informix, msql, mssql, mysql, mysqli, oci8, odbc, pgsql, sqlite and sybase. I know this sounds ambitious, and if someone can give me good arguments not to take this road (or give me good ones to go for it immediately), now is the time. After doing the above and releasing a 2.0 version, it would be nice to implement some of the remaining RFE's like flexible task management, add relationships (aka other project mngt sw), time registration and billing, etc. It won't be a quick development track, but it will bring a lot of good stuff. I'd really appreciate any comments. Best regards, Martin Vernooij Tiempo Project- & Interim Management, Webhosting Services The Netherlands |
|
From: Martin V. <mar...@ti...> - 2004-10-23 19:36:30
|
>I think this one is for Guy, but if someone else has a >solution I'll be glad to hear it. It appears this had nothing to do with Guy's scripts. Triggered by an OL mail from Bogdan, I found the syncmail script on the CVS server for Outreach was quite out of date. And because SF upgraded Python and couple of other stuff, the old script did not work anymore. It's now been fixed by installing the latest version of syncmail. So off we go..... updates and additions to OPT can be committed and all of us will get a notification and you don't get error messages. >Martin |
|
From: Martin V. <mar...@ti...> - 2004-10-22 07:21:00
|
I think this one is for Guy, but if someone else has a solution I'll be
glad to hear it.
I've tried to commit my first change today, but I get the following
error:
mvernooij@tiempol10:/home/vhosts/optdev/opt/setup$
cvs -d:ext:mar...@cv...:/cvsroot/outreach commit -m "Removed
requirement for opt_user to have MySQL FILE permissions. All initial
tables and data are now in opt_init.sql" setup.php opt_init.sql
mar...@cv...'s password:
Checking in setup.php;
/cvsroot/outreach/opt/setup/setup.php,v <-- setup.php
new revision: 1.11; previous revision: 1.10
done
Checking in opt_init.sql;
/cvsroot/outreach/opt/setup/opt_init.sql,v <-- opt_init.sql
new revision: 1.24; previous revision: 1.23
done
Mailing out...@li......
Generating notification message...
Generating notification message... done.
Mailing out...@li......
Generating notification message...
Traceback (most recent call last):
File "/cvsroot/outreach/CVSROOT/syncmail", line 322, in ?
main()
File "/cvsroot/outreach/CVSROOT/syncmail", line 315, in main
blast_mail(subject, people, specs[1:], contextlines, fromhost)
File "/cvsroot/outreach/CVSROOT/syncmail", line 221, in blast_mail
conn.connect(MAILHOST, MAILPORT)
File "/usr/lib/python2.2/smtplib.py", line 276, in connect
for res in socket.getaddrinfo(host, port, 0, socket.SOCK_STREAM):
socket.gaierror: (-2, 'Name or service not known')
mvernooij@tiempol10:/home/vhosts/optdev/opt/setup$
If I check the CVS tree and the outreach_CVS mailing list, nothing is
committed. I guess I'll need some of the scripts Guy mentioned in a
previous message?
best regards,
Martin
|
|
From: Martin V. <mar...@ti...> - 2004-10-15 07:47:21
|
Hi Grant, GB>MV> I have reviewed all available information about the status of the GB>MV> project and I'd like to propose the following steps to work GB>MV> towards next releases and further improvements: GB> GB>Your 'next steps' seem very good to me. I am happy to help with bug GB>fixing where I can, as well as on the list of my personal priorities. GB> GB>I couldn't easily read your annotated bug list - came out formatted GB>strangely on my mail system, but I agree you should remove GB>items which GB>are resolved or no longer relevant. Maybe it's a bit better readable on the list https://sourceforge.net/mailarchive/forum.php?thread_id=5763738&forum_id =35805, and I have to agree that the line length shot me in the feet.... GB>Some of the issues I listed overlap with those on the RFE list. Agree, suppose it would probably be nice if you could give your priority on those and I'll start chasing the bugs. Just to divide the work and get to the 1.3 release "quickly". GB>I am not yet clear on the process for making changes... I GB>guess I need GB>to install the current CVS version on my side and make changes from GB>that... I will try to read up on this over the weekend - it's just GB>that I haven't done it before. If anyone has a brief step-by-step for GB>me I would appreciate it. You definitely need to install the cvs. I assume you have a Linux/Unix development server. You'll need to have the cvs client package. I use Debian, which gives you easy access to a load of packages easily with apt-get (or dselect for the ones menu oriented). The usage of Sourceforge CVS is pretty well summarized on the site: Basic Introduction to CVS and SourceForge.net (SF.net) Project CVS Services, which can be found at https://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1. Also be aware, that before you start working, you either change the modified field in the database or create a development database by executing the CVS install. The 1.2.5 versions differs from the cvs in this respect. Another reason to go at least for a 1.2.6 version soon. ,-) Regards, Martin |
|
From: Grant Ballard-T. <gr...@ec...> - 2004-10-14 13:38:48
|
Martin, Thursday, October 14, 2004, 1:48:31 PM, you wrote: MV> I have reviewed all available information about the status of the MV> project and I'd like to propose the following steps to work MV> towards next releases and further improvements: Your 'next steps' seem very good to me. I am happy to help with bug fixing where I can, as well as on the list of my personal priorities. I couldn't easily read your annotated bug list - came out formatted strangely on my mail system, but I agree you should remove items which are resolved or no longer relevant. Some of the issues I listed overlap with those on the RFE list. I am not yet clear on the process for making changes... I guess I need to install the current CVS version on my side and make changes from that... I will try to read up on this over the weekend - it's just that I haven't done it before. If anyone has a brief step-by-step for me I would appreciate it. Regards Grant |
|
From: Martin V. <mar...@ti...> - 2004-10-14 12:50:44
|
Below an initial review of the open bugs currently at Sourceforge. My
recommendations are per item. I welcome any comments. Next week I'll
start updating each bug report with the recommendation/comments and/or
close them. As bugs are Priority 1 for me, I'll start working on these
first. Hopefully I can release a 1.2.6 version in a not too long
timeframe.
ID Summary
1043075 1.2.5 Max: Install scripts creates invalid (demo)users *
2004-10-08
Simple - assign to martinfst
986745 Can not post to task forum * 2004-07-07
Well documented, partly fixes included - assign to martinfst
961139 XML in Paragraph * 2004-05-26
Well documented, partly fixes included - assign to martinfst
960924 Wrong Locale id for german * 2004-05-26
Well documented, quite some work, as I recall other comments
in the
translation area (broken?) - assign to martinfst
910877 Cannot select some directories when adding/editin a document *
2004-03-06
This has been reported several times, but both Lanifex as
myself
have not been able to reproduce this. I'll do some more
investigation
in the code, but if I can't find anything, I'll add a comment
to this
bug that we need a sample of a non-working environment before
further
investigation can be done. - assign to martinfst
900010 JavaScript date pickers fail on Safari (Mac OS X) * 2004-02-19
Investigate the documented fix (new script suggestion). I
don't
have access to MacOS/Safari, so it's up to a Mac volunteer to
test the fix.
assign to martinfst.
837097 Error message from opt while editing a request * 2003-11-06
Seems non-reproducible, is reported against 1.2.0, so I
suggest to close
this one.
819960 OPT_MAX 1.1: session reset if user does not logout * 2003-10-08
Have to investigate this further, but it also relates to the
whole session
management, which I plan to review for the 1.3 release. (see
later)
- assign to martinfst
800965 re opening bug: #795344 sql syntax * 2003-09-05
Quoting should be revisited in the app and be fixed where
required. Quite
some work, but I think this could use some priority. Although
this seems quite
old, it still happens in 1.2.5 (especially the n/a) - assign
to martinfst
756909 Symbols in document descriptions * 2003-06-19
Check for this in 1.2.5, but I think it's still there and
related to the one above
(quoting) - assign to martinfst
697232 impossible to install opt version OPT_0.946b. * 2003-03-04
Old and not very actual. Suggest to close this one.
655937 Mime type needs file to update * 2002-12-18
Also for 0.9 version, but I'll check if it still exists in
1.2.5. If not just close
this bug. - assign to martinfst
649077 warning: variable passed to each .. * 2002-12-05
Has to do with sending mail to multiple recipients. I believe
this works in 1.2.5
so I suggest to close this request.
644693 Calendar 1.07 error * 2002-11-27
For 0.9 version, using plugins. As 1.2.5 has no plugins and
calandar seems to work
I suggest to close this request.
620549 Email parsing bug when using aliases * 2002-10-09
This one does not exist in 1.2.5, so just close.
605052 Overview page SQL error .948 * 2002-09-05
Old version (0.9) and relates to possible incorrect quoting,
which is on the list
anyway. Suggest to close this request.
605021 Overview page SQL error .948 * 2002-09-05
Identical to above. So can be closed anyway.
603539 0.948: upgrade 'forgets' task forum * 2002-09-02
Old version and bug in upgrade script from 0.947 to 0.948.
I believe this can be closed.
603536 0.948: parse error in hours.php line 89 * 2002-09-02
hours.php does not exist anymore in 1.2.5, so I suggest to
close this bug request.
597256 Inactive Project Tasks in Overview * 2002-08-19
This "bug" is still valid in 1.2.5. As task will still
appear active on the
overview page, even though the project it belongs to is set
to inactive.
A check should be for unfinished tasks when making a project
inactive, and
ask for a confirmation. Give the option to leave tasks open
on personal
pages or remove them as active tasks. (no hours should be
booked against it
either.
593193 Gettext version short or long codes * 2002-08-09
Has to do with translations/multiple languages, which should
be revisited anyway.
Leave open until a new language scheme is finished.
Best regards,
Martin Vernooij
|
|
From: Martin V. <mar...@ti...> - 2004-10-14 12:48:42
|
I have reviewed all available information about the status of the
project and I'd like to propose the following steps to work towards next
releases and further improvements:
prio 1. Bug fixing
----------
Currently there are 21 bugs reported in the bug tracker
https://sourceforge.net/tracker/?atid=410239&group_id=34206&func=browse.
The majority is old and relates to 0.9 versions, the version originally
released/maintained by Lanifex. There might be one or two still present
in the current 1.2.5 Max release, but that seems very limited to me. In
order to improve the 'image' of the project on Sourceforge and
reduce/remove confusion for visitors, I suggest I review in depth all
bugs, check if the bugs are present/reproducible in the Max version, and
if not, just close it. At the end we should be left with a list of bugs
only "valid" for the Max release. In a separate message my initial
conclusions/recommendations per bug issue will be explained.
During review, fixes should be created/implemented and a new 1.2.6
version (stable) should be released when done with fixing the known
errors.
Prio 2. Support requests
----------------
There's another list in use, Support Request, which is used for bugs and
questions:
https://sourceforge.net/tracker/?atid=410240&group_id=34206&func=browse.
I will check each of the 14 items on this list, of which 50% relates to
0.9 versions. If they are no longer valid, I'll just close them. Same as
above, having requests open with a very old version and with a date of 2
years ago, that doesn't give much confidence.
Prio 3. Remove register_globals dependency
----------------------------------
This can be done two ways:
either do the short fix as Bogdan suggested using a common script:
extract($HTTP_GET_VARS);
extract($HTTP_POST_VARS);
extract($HTTP_COOKIE_VARS);
extract($HTTP_SERVER_VARS);
or rewrite the session management completely. I prefer the latter, as I
know there are currently some quite hard to find issues with users
logging-off and causing session aborts of other logged-in users and
problems with users closing their browser without logging-off. I believe
this should give us a 1.3.0 version. Perhaps we can include the LDAP
authentication (see prio 3 also) in this as well. And perhaps we should
make authentication even more flexible, to allow for PAM or SASL
(including MySQL storage) as well.
Prio 4. fix multi-language usage
------------------------
The translations are also in the bug list, but if they don't get fixed
there, this should be the time to start working on them, having fixed
all the previous priorities. Languages should be easily editable and
distributable. Even multi-language usage within one site should be
possible. This is probably quite some work.....
Prio 5. Suggestions on dev list from Grant
----------------------------------
Grant made several suggestions, which would make OPT more suitable for
his environment. I'll repeat them here, but if we agree and divide the
development load, I think each suggestion should be entered as an
individual request on the RFE tracker list, including the comments that
already have been given. If all agree, Grant can you create the
individual requests on the RFE list? After each request is on the list,
we'll have to assign priorities and plan for releases. So putting this
for me on prio 5 doesn't mean there aren't valid and usefull suggestions
on which development can start soon. It won't be me though to start
working on these with top priority. I'd like to chase the ones suggested
above first. I suggest we'll build /add new features starting with the
1.3 release.
BTW: in the Sourceforge Patch area, there's already a patch submitted
for LDAP authentication. It's from early 2004, so it might be against a
1.2 version. Probably worth investigating.
Prio 6. Update the Project home page
------------------------
I set this to 6, but like to get some updates on the project website
sooner. The current page presents old information, showing screenshots
of the 0.9 version and lacks a proper demo site. I'd like to start
working on this ASAP. To make visitors interested in OPT and show
up-2-date information this is the least we can do. I'm hoping that
Lanifex can help us here, as the page clearly shows the original
developer(s) ;-)
Anyway, I will soon setup a demo server as well with the latest working
CVS release. We could point to this as well for demo purposes.
Prio 7. Revisit the RFE list
--------------------
The RFE list contains 25 requests for enhancements. Some requires little
effort, some a bit more and some propose a complete rewrite (like
removing the frames usage and go for a templating system, which BTW
seems to be cool to me). As we'll have significant work to fix couple of
things, I'd like to review the RFE list later on when we have a stable
1.3 version. Most RFE's are already quite old, but still valid. Probably
doesn't hurt if they stay on the list for next couple of weeks.
Prio 8.
Add MD5 checksums and PGP key signing to enable verification and
authentication of the distributions.
Best regards,
Martin Vernooij
|
|
From: Guy D. <da...@gu...> - 2004-10-08 23:55:49
|
Martin wrote: > Hmm, a SQL change you say? I initially created the database with 1.2.5 > and then installed the CVS version and said it should use the existing > database. I"ve not encountered any errors yet. Do you remember > specifics? As with everything code related, please see CVS and check the diffs: http://cvs.sourceforge.net/viewcvs.py/outreach/opt/setup/opt_init.sql?rev=1.23&view=log Notice the change that was committed after 1.2.5 was tagged. Guy |
|
From: Martin V. <mar...@ti...> - 2004-10-08 15:25:05
|
Hi Guy, fully agree to use the general lists for these discussions. Saves also a big CC-list ;-) For the sake of completeness I'll just copy the previous conversation in this message so everybody can contribute to the discussion. Having said that, my purpose of this discussion is to create a new roadmap (no timelines! before anybody asks) so we know where we're heading. Martin GD>Hi Grant and Martin, GD> GD>Just a couple of recommendations: GD> GD>1) Please use the outreach-devel list for these types of discussions. GD>Please post development SQL changes there. Agree, see full discussion below. GD>2) My deployment script will automatically replace the 6.6.6 version GD>with whatever build you're creating. Definitely start with GD>the version GD>in CVS. There are some minor bug fixes in there and I think I have an GD>SQL change. Hmm, a SQL change you say? I initially created the database with 1.2.5 and then installed the CVS version and said it should use the existing database. I've not encountered any errors yet. Do you remember specifics? GD>3) Before deleting functionality, be sure that you ask the user list GD>whether they're using it. For example, we use the PDF preview for GD>documents all the time as the developers use Open Office which GD>our other GD>staff don't have. Everybody has Acrobat viewer though. I'm not going to delete any functionality. This specific changes will enable to switch the PDF column off. The default will be on, so it will look the same. GD>4) The CVS commit logs you make are used to generate the Changelog for GD>deploys, so try to use descriptive comments that users will understand. I'll try. Latest 1-2-1 message from Grant follows --------------------------------- Dear Martin, Thanks for the feedback, and very much 'thanks' for 'stepping forward' More comments below: >> >>Anyway, here is my current list of issues to track down / address >>(some may already be features, but I couldn't find them): >> >>* Choose whether to use Mr / Name / Surname in emails to users (always >>seems to address people as Mr XXX which is a little odd if we call >>each other by first names. MV> Should be configurable? Yes, an option "Name to use in correspondence" >> >>* project category defaults - I seem to have to set up categories fresh >>for each new project... major waste of time since my company has >>standard categories which need to be used MV> Sounds specific for your company. Every user will probably have their MV> own catagories or even per project categories. Perhaps a simple MySQL MV> script is sufficient? Each 'default setting' would be company specific. But what I am saying is that we need to have an option to set the defaults to whatever the particular company wants. A script might do this if the OPT user can easily create it. The script would run on creation of a project, setting up a number of defaults - directories in the document folder, categories, perhaps initial and closing tasks (all projects have some common tasks (preparation and dealing with paperwork for example), etc. etc. What I am saying is that it would be neat if one could set up default settings for projects - maybe do this by creating one project which becomes the template / boilerplate for the other projects. Then when creating a new project one chooses "Use project 'template' as model" - and hey presto everything is created ready for tailoring to a specific situation. >> >>* other project defaults - default document folder package for new >>projects - each project should have the same basic setup I think. MV> Same as above? Indeed. >> >>* better access to project categories - linked to above... I have to >>dig deep to find where to set these for each project MV> Help should probable be improved, but most likely also the "menu" MV> structure. Seems generic. Yes, I shouldn't need to use help - it should be intuitive. Let me say though, that I think it is very good right now... just flagging up a few issues I would like to see. >> >>* PDF preview - what is it? Why? I don't need this generally, and >>certainly don't have time to make PDFs of my documents. See "Disable >>features not needed" below MV> Good improvement suggestion, if it's configurable. Pdf's are very MV> usefull if you have a large team with mixed sw and you don't want to MV> purchase a license for everyone of a specific software tool (e.g. MS MV> Project is mostly only req'ed for project managers, but team members are MV> interested in specific MS Project reports). Uploading a pdf will enable MV> everyone to see the output/data. Also usefull if you want to create a MV> non-changeable snapshot of a document. Sure - I would like to add PDF files once in a while, but most of the people working in my projects can't/won't make PDFs, and will phone me up to find out "what is this PDF preview thing?"... anyway, the key here is to be able to disable some features if they are not wanted. Could one, for example, remove the knowledge base - if I personally don't want my system to use this. What if I don't want a forums for projects to be available? These things should be made configurable if they aren't already. >> >>* Company archive - I need a general company / system document archive >>where we can put in templates for letters, faxes, etc. MV> Couldn't you use the general project->documents folders and use a MV> project called Administration, accessible for everone? Of course I could. Maybe that is the way to do it best - I just immediately looked for somewhere to put company documents, not project documents. Of course making an admin project is one way to do it. >> >>* Disable features when not needed: I would like to be able to remove >>various features (eg PDF preview) which are likely to confuse my users >>(they are all non computer users...) MV> Oke if configurable It should be made configurable if it isn't! >> >>* Calender - allow to show a text list of tasks (listview) - couldn't >>find that MV> Not sure what you mean... It's not always convenient to have a calender view according to date. Rather just a list of all the tasks. Maybe 'my tasks' provides this, but I'm not sure it's sorted - or displays start and due dates. I should think about this a bit more... >> >>* Other date formats? Seems to want to use 2004-10-8 as layout - can I >>set it to 8-10-2004 ? maybe this already can be done? MV> As fas as I know, it can't be changed now. Good point. The date format MV> should become a setting. The dates are already stored in epoch format, MV> so that's easy. Now only change all places where date is displayed..... Yes, under admin there should be an option to set date 'locale' so one can enter dates in a preferred local format. >> >>* Calender - weekview, 4 month view? MV> Sure. >> >>* Can we make knowledge (and perhaps other sections) into a wiki? No >>'history' needed, but to have pagenaming and pagelinking wiki style >>would greatly improve usefulness. Also knowledge articles should be >>able to link easily to reference documents, urls etc. as needed MV> Wiki seems to gain popularity ;-) Good point. I've never used the MV> knowledge sharing element of OPT, and I don't know how this will MV> interfere with existing knowledge sharing as is done now by OPT. Even MV> don't know is this is often used. In fact I like Wiki more than email for group planning / discussion. Here people add and improve things instead of sending mail back and forth or submitting forum items, which then are difficult to track project status, agreements, planning. Email / forum is good to show new project members what has been happening, but not good to show current decisions. I would like to make minutes, and insert into them "To access the project proposal, click here. To view agreed procedure for working with XXX client see the knowledge article XXXABC.". When I make a task, I would like to be able to add a link to a document (many tasks may refer to the same document, so no point in reloading it again and again) knowledge article, etc - ie I want a simple way of making hyperlinks between issues. >> >>* Is there some way to edit knowledge entries? couldn't find any! MV> Don't know. I couldn't find it - only 'delete'... knowledge needs to be easily editable. >> >>* templates for reports / minutes - these need to be company formatted >>- letterhead etc, and there should be a way to set up the templates. MV> Templating system? On other projects is used HTML::Template (Perl MV> though). Something similar could be usefull. I don't mean templates to change the look of OPT, but if I make minutes (which are created in PDF), I would like to set standard headers, typefaces, etc. to give it a company identity. >> >>* make meetings through calender? MV> As sending meeting request to MS Outlook/Exchange(/Notes)? Perhaps this is just a link to make a task (meeting for instance), straight from the calender view. >> >>* milestones - I don't see any way to set these unless I set a one-day >>task. I need to think through what I am looking for here, but wondered >>how I could do it. MV> Struggled with these previously also. Room for improvement I would say. >> >>* Under tasks, how do you say you have completed one? I allocated >>time (register hours), and tried all sorts of things to do this before >>somehow achieving it (can't even remember how now.) MV> A task is completed when remaining hours are set to 0 (zero). Would be MV> nice to have an option to mark a task complete. However there's a caveat MV> here. If remaining hours is zero, nobody can register hours on this MV> task, even if these hours are done in the past. You'd the have to give MV> it 1 hour of so, and teammembers can complete their timesheets. The MV> progress charts become very ugly then, as you have allocated an hour MV> maybe after weeks. It also shows up as overdue tasks in overviews, MV> untill you set the remaining hours to 0 again. This is not efficient. When the work on a task is done it must be marked so - of course timesheets may come in a week later, but done is done, and it must disappear from to-do list. >> >>* Use my current LDAP databases? Not productive to retype all the >>contacts and maintain data in various databases, updating them all. MV> I think authetication needs a review anyway. Having multiple users on MV> the same project can have a impact on each other. I still have an MV> bug-report open where if one user logs-off other user sessions get MV> killed also. LDAP should be optional, but very usefull. (I personally MV> have no practical experience with LDAP yet) Yeah. I don't particularly look for authentication through LDAP, but I have all contacts / customers data already in a LDAP server. It is a waste of time to type in the contact details again and spend hours setting up. If I do a project with X, I should be able to haul data from the LDAP server. Also, if the telephone number of a client is changed in our 'enterprise wide' LDAP, I don't want to have to dig into OPT and change it there. Why do things twice. By the way, the LDAP have about 1000 addresses, so it is no small task to get address data into OPT and keep it uptodate in both OPT and LDAP. Martin - thanks for your efforts and enthusiasm. Grant |
|
From: Grant Ballard-T. <gr...@ec...> - 2004-10-08 15:21:07
|
Dear Guy, Thanks - just briefly, (and I will sign up for outreach-devel asap): GD> 3) Before deleting functionality, be sure that you ask the user list GD> whether they're using it. For example, we use the PDF preview for GD> documents all the time as the developers use Open Office which our other GD> staff don't have. Everybody has Acrobat viewer though. I'm not suggesting deleting anything, just making things configurable / optional. If one needs it "enable it", if not "disable it". This way users don't get confused with things they don't need to know about. Thanks again, Grant |
|
From: Guy D. <da...@gu...> - 2004-10-08 14:58:28
|
Hi Grant and Martin, Just a couple of recommendations: 1) Please use the outreach-devel list for these types of discussions. Please post development SQL changes there. 2) My deployment script will automatically replace the 6.6.6 version with whatever build you're creating. Definitely start with the version in CVS. There are some minor bug fixes in there and I think I have an SQL change. 3) Before deleting functionality, be sure that you ask the user list whether they're using it. For example, we use the PDF preview for documents all the time as the developers use Open Office which our other staff don't have. Everybody has Acrobat viewer though. 4) The CVS commit logs you make are used to generate the Changelog for deploys, so try to use descriptive comments that users will understand. Guy |
|
From: <ben...@id...> - 2004-05-25 08:40:15
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Nicolas W. <we...@ma...> - 2004-03-09 11:09:48
|
Hello. My company has decided to give a try to OPT for managing teams. There are a few things we'd want to fix (like you can't use , in worked hours, pretty bad for us who use it instead of .). So I grabbed Sourceforge's CVS, which apparently isn't really the last version. My question would therefore be: is there a cvs somewhere with latest version? and if i change something, and wish to submit a patch, where should i send it? to patch tracker? Many thanks in advance :) Nicolas Weeger |
|
From: Guy D. <da...@gu...> - 2004-01-03 23:12:38
|
I've just added functionality to OPT to connect to a CVS repository via its 'loginfo' file to parse all commit messages for OPT task numbers. If a task number is found, it is stored in the database and can be viewed from the OPT task details page among others. For anyone using OPT from the CVS version, please add the 'cvs_files' and 'cvs_commits' tables that have been added to include/opt_init.sql manually. As well, you should have a file called include/init_cvs_parse.txt. Copy it to include/cvs_parse.pl and change the temp dir directive to match the one in mail_retrieve.pl. This will be all done automatically for those using the standard OPT distributions. These instructions are just for developers or users who are running OPT directly from an SF CVS extract. Let me know if you notice any problems with these changes. Guy |
|
From: Guy D. <da...@gu...> - 2003-10-22 18:59:42
|
I've applied a modified version of this patch with some corrections. The
SQL statement added a setting of a different name than was referenced in
the code. As well, it was possible to collapse your patch's if, else
logic and avoid the duplication of code it caused.
Please update your repository to see the modifications I made. Also,
ensure your local version is using the correct setting name.
For anyone using OPT Max from the CVS version, please run the following
SQL to both your opt and opt_demo databases:
INSERT INTO project_settings (project, name, value, default_val) VALUES
(0,'auto_select_entire_team_as_involved_in_a_new_task','0','0');
Guy
Shubhankar Bera wrote:
>Hi Guy,
>
>Here are the patches for auto task assignment when a new task is created.
>The project setting has been changed to
>'auto_select_entire_team_as_involved_in_a_new_task'. Also, the help
>document has been updated.
>
>I also updated add_form.inc so that if an already created task is being
>edited, the people previously selected in the "others involved" picklist
>are the only ones selected while in the edit screen (even if the auto
>select variable is set).
>
>Thanks,
>Shubhankar
>
>
>------------------------------------------------------------------------
>
>Index: add_form.inc
>===================================================================
>RCS file: /cvsroot/outreach/opt/tasks/task/add_form.inc,v
>retrieving revision 1.8
>diff -r1.8 add_form.inc
>35a36
>
>
>> $editing_task = 1;
>>
>>
>326a328
>
>
>> $is_team_task = get_project_setting($proj, "auto_select_entire_team_as_involved_in_a_task");
>>
>>
>332,337c334,365
>< if (@in_array($id,$people)) {
>< $checked="selected";
>< } else {
>< $checked="";
>< }
>< echo "<option value='$id' $checked>".$fname." ".$lname."</option>\n";
>---
>
>
>> if ($is_team_task == 1)
>> {
>> if ($editing_task != 1)
>> {
>> $checked="selected";
>> echo "<option value='$id' $checked>".$fname." ".$lname."</option>\n";
>> }
>> else
>> {
>> if (@in_array($id,$people))
>> {
>> $checked="selected";
>> }
>> else
>> {
>> $checked="";
>> }
>> echo "<option value='$id' $checked>".$fname." ".$lname."</option>\n";
>> }
>> }
>> else
>> {
>> if (@in_array($id,$people))
>> {
>> $checked="selected";
>> }
>> else
>> {
>> $checked="";
>> }
>> echo "<option value='$id' $checked>".$fname." ".$lname."</option>\n";
>> }
>>
>>
>>------------------------------------------------------------------------
>>
>>Index: opt_init.sql
>>===================================================================
>>RCS file: /cvsroot/outreach/opt/setup/opt_init.sql,v
>>retrieving revision 1.18
>>diff -r1.18 opt_init.sql
>>1187a1188
>>
>>
>>>INSERT INTO project_settings VALUES (16,0,'auto_select_entire_team_as_involved_in_a_new_task','0','0');
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>Index: help.txt
>>>===================================================================
>>>RCS file: /cvsroot/outreach/opt/setup/help.txt,v
>>>retrieving revision 1.10
>>>diff -r1.10 help.txt
>>>622a623,624
>>>
>>>
>>>><b><code>auto_select_entire_team_as_involved_in_a_new_task</code></b>: When active (1), the entire team is automatically selected in the "others involved" picklist when creating a new task. When inactive (0), team members involved in task have to be selected manually.
>>>>
>>>>
>>>\
>>>
>>>
>>>>
>>>>
>>>>
>>>\
>>>
>>>
|
|
From: Guy D. <da...@gu...> - 2003-10-21 05:13:47
|
Shubhankar Bera wrote: > Here are the patches for the Helpdesk Task assignment request. When the > "allow_helpdesk_tasks_to_be_edited_by_entire_helpdesk" project setting is > set to 1, all team members are automatically added in "others > involved". The only change made here is the automatic selection of team > members (we were able to select them manually before). Can you change the name of the setting to: "auto_select_entire_team_as_involved_in_a_new_task" and resubmit the patch. The "HelpDesk" group is specific to our company so it won't necessarily make any sense to other OPT Max users. Also, this patch requires changes to the OPT Help documentation. Stop by my office tommorrow and I'll show you how to do that. Guy |
|
From: Guy D. <da...@gu...> - 2003-10-20 19:10:01
|
Shubhankar Bera wrote: >Here are the patches for the changes I have made for when a request is >deleted. Patch1 is just the code formatting so that it is upto our coding >standards. Patch2 is where the changes to the actual code have been done. > >When a request is deleted, the program will check all tasks that are >associated with the request. If a task has no work done and is not >associated with any other request, it is deleted. If a task has no work >done, but is associated with other requests, it will remain associated >with the other requests. If a task has any work done, it will not be >deleted (if it is associated with other requests, the association will >remain, but if it isn't associated with anything else, it will become a >standalone task). > >I have tested the changes I made with a few test cases and it seems to >work as expected. If you have any problems with it once you've tested it, >please let me know and I'll make the required changes. > > Just applied this patch. Only changes were to break some of the particularly long lines (mostly strings) and to remove comments indicating a change date (such as "On October 10th..."). The change dates are not necessary in code comments as CVS handles all that. Thanks for the patch. This fix will be appreciated by the users. Guy |
|
From: Guy D. <da...@gu...> - 2003-10-16 22:12:21
|
Shubhankar Bera wrote: >Here is the patch for the width of the picklists. I've tried it out on my >local system and it seems to work well. If you have any problems with it >after you've tried it out, let me know. > Applied. I narrowed the limits from 20 to 15 to gain a little more space. Also, I need to remove some commented out debugging code you'd left in. Please try to remove this from future patches. Thanks. |
|
From: Guy D. <da...@gu...> - 2003-10-13 22:24:23
|
Hi all, I just added a rather large commit to the OPT Sourceforge CVS repository containing new functionality for CVS browsing from within OPT. If you are using the latest code from the SF CVS, please create the following table in both your opt and opt_demo databases. CREATE TABLE code_repositories ( id mediumint(8) unsigned NOT NULL auto_increment, project mediumint(8) unsigned NOT NULL default '0', name char(16) default '', title char(64) default '', location char(255) default '', cvsusers char(64) default '', root_dir char(128) default '/', restrictions char(255) default '', PRIMARY KEY (id), INDEX (project) ); If you're using an official release of OPT (1.1.0 for example), please disregard this message as the upgrade process will add this table for you automatically. Guy |