|
In-Portal Issue Tracker - In-Portal CMS
|
|
Viewing Issue Advanced Details |
|
|
ID:
|
Category:
|
Type:
|
Reproducibility:
|
Date Submitted:
|
Last Update:
|
|
309 |
[In-Portal CMS] Install / Upgrages |
bug report |
always |
2009-09-20 08:32 |
2009-10-03 07:56 |
|
|
Reporter:
|
alex |
Platform:
|
|
|
|
Assigned To:
|
alex |
OS:
|
|
|
|
Priority:
|
normal |
OS Version:
|
|
|
|
Status:
|
closed |
Product Version:
|
5.0.0 |
|
|
Product Build:
|
|
Resolution:
|
fixed |
|
| |
|
ETA:
|
none |
Fixed in Version:
|
5.0.1 |
|
|
Reference:
|
|
|
Change Log Message:
|
|
|
Estimate Points:
|
0 |
|
|
Summary:
|
0000309: Strange things in modules list (only In-Portal module installed) |
|
Description:
|
There are few strange things about how "Modules" section looks now:
1. there are two "Ready to Install" links instead of one;
2. Column "Build Date" shows either "01/01/1970 3:00 AM" (for installed modules) or "NO SUCH FIELD" (for not installed modules).
3. "Order" column doesn't provide any useful information since user can't change order of the installed modules.
Column "Build Date" usually is filled with current date (correct me if I'm mistaken) during time, when module is downloaded from site. In all other cases, like "direct svn checkout", "snapshot being used" this field is empty resulting 1 January of 1970 year to be shown. If this column is really needed, then it should at least "NULL" by default. Also build date is not available for modules, that are not yet installed and that creates the confusion, for ex. when module not installed date not shown, but after it's installed date suddenly appears and it looks-like that date appearance had something to do with module install fact.
If build date is really needed, then I propose to move this date to "module_info.xml" file to be able to show it even before module install. I propose to automatically update this date in "module_info.xml" file for each module during it's release process, not in script, that downloads it from site. This way there always be current release date (for released versions) and previous release date (for versions currently in development).
Same with Order column: if needed, then move module order to module_info.xml (I think something like this is already in "install_order.txt" file for each module). |
|
Steps To Reproduce:
|
|
|
Additional Information:
|
|
| Relationships | |
|
Attached Files:
|
|
|
|
Issue History |
|
Date Modified |
Username |
Field |
Change |
|
2009-10-03 07:56 |
administrator |
Note Added: 0000696 |
|
|
2009-10-03 07:56 |
administrator |
Status |
resolved => closed |
|
2009-10-03 07:46 |
administrator |
Priority |
@60@ => normal |
|
2009-09-22 07:02 |
alex |
Fixed in Version |
=> 5.0.1 |
|
2009-09-22 07:01 |
alex |
Changeset attached |
5.0.x r12587 |
|
2009-09-22 07:01 |
alex |
Note Added: 0000508 |
|
|
2009-09-22 07:01 |
alex |
Status |
reviewed and tested => resolved |
|
2009-09-22 07:01 |
alex |
Resolution |
open => fixed |
|
2009-09-22 06:58 |
alex |
Changeset attached |
5.0.x r12586 |
|
2009-09-22 06:58 |
alex |
Changeset attached |
5.0.x r12585 |
|
2009-09-22 06:57 |
alex |
Changeset attached |
5.0.x r12584 |
|
2009-09-22 06:57 |
alex |
Changeset attached |
5.0.x r12583 |
|
2009-09-22 06:57 |
alex |
Changeset attached |
5.0.x r12582 |
|
2009-09-22 06:53 |
alex |
Changeset attached |
1.0.x r12581 |
|
2009-09-22 06:50 |
alex |
Changeset attached |
1.0.x r12580 |
|
2009-09-22 01:34 |
Dmitry |
Priority |
normal => @60@ |
|
2009-09-21 16:07 |
Dmitry |
Note Added: 0000504 |
|
|
2009-09-21 16:07 |
Dmitry |
Assigned To |
Dmitry => alex |
|
2009-09-21 16:07 |
Dmitry |
Status |
needs work => reviewed and tested |
|
2009-09-21 16:05 |
alex |
Note Added: 0000503 |
|
|
2009-09-21 16:05 |
alex |
Assigned To |
alex => Dmitry |
|
2009-09-21 16:05 |
alex |
Status |
needs feedback => needs work |
|
2009-09-21 11:32 |
Dmitry |
Note Added: 0000499 |
|
|
2009-09-21 11:32 |
Dmitry |
Assigned To |
Dmitry => alex |
|
2009-09-21 11:32 |
Dmitry |
Status |
needs work => needs feedback |
|
2009-09-21 03:20 |
alex |
Target Version |
=> 5.0.1 |
|
2009-09-21 01:32 |
alex |
Note Added: 0000494 |
|
|
2009-09-21 01:32 |
alex |
Assigned To |
alex => Dmitry |
|
2009-09-21 01:32 |
alex |
Status |
needs feedback => needs work |
|
2009-09-21 01:27 |
alex |
Note Edited: 0000491 |
bug_revision_view_page.php?bugnote_id=0000491#r235 |
|
2009-09-20 23:31 |
Dmitry |
Note Edited: 0000491 |
bug_revision_view_page.php?bugnote_id=0000491#r234 |
|
2009-09-20 23:30 |
Dmitry |
Changeset attached |
5.0.x r12576 |
|
2009-09-20 23:25 |
Dmitry |
Note Added: 0000491 |
|
|
2009-09-20 23:25 |
Dmitry |
Assigned To |
Dmitry => alex |
|
2009-09-20 23:25 |
Dmitry |
Status |
needs work => needs feedback |
|
2009-09-20 23:17 |
Dmitry |
Status |
needs feedback => needs work |
|
2009-09-20 08:32 |
alex |
Assigned To |
=> Dmitry |
|
2009-09-20 08:32 |
alex |
Status |
active => needs feedback |
|
2009-09-20 08:32 |
alex |
New Issue |
|
|
Notes |
|
|
(0000491)
|
|
Dmitry
|
2009-09-20 23:25
(edited on: 2009-09-21 01:27) |
|
Strange behavior in Modules grid is fixed!
Thanks for valid review, here is what I think is a good option for Build and Order fields:
1. BuildDate is when the software was installed or upgraded. In our case we are talking about module. It's not actually related when it was downloaded or released. This specifically indicates when it was installed.
I say we get this working in 5.0.1:
- Module NOT installed -- field is empty (Null)
- Module installed -- field has installation date
- Module upgrades -- field updated during the upgrade
2. Order field - yes, for the moment Admin can't control this, however I see no complications allowing to change Order when modules loaded UP /DOWN. We just need to refresh Cache + Left Nav, Tree.
This can be useful for people with multiple modules.
I say we submit this as a Feature for 5.1.x and comment out from the Grid for the time being.
Let me know your thoughts.
|
|
|
|
(0000494)
|
|
alex
|
|
2009-09-21 01:32
|
|
Changing module order won't affect how system processes them, e.g. order of sections in tree. That order is used only internally to be sure, that e.g. In-Commerce is loaded before In-Auction and Core is loaded before any other module.
Maybe this is not used at all anymore, maybe only for licensing purposes some how. |
|
|
|
(0000499)
|
|
Dmitry
|
|
2009-09-21 11:32
|
|
1. Agreed on Order column - I'll be removing it from the Grid shortly.
2. What you think on the BuildDate approach described above? |
|
|
|
(0000503)
|
|
alex
|
|
2009-09-21 16:05
|
|
|
|
|
(0000504)
|
|
Dmitry
|
|
2009-09-21 16:07
|
|
|
Proceed with BuiltDate implementation. |
|
|
|
(0000508)
|
|
alex
|
|
2009-09-22 07:01
|
|
Fix committed to 5.0.x branch. Commit Message:
1. Fixes 0000309: Strange things in modules list (only In-Portal module installed).
2. Now tracking of "In-Portal" module version is done automatically (no need for changes in install_data.sql or upgrades.sql files.
3. On upgrade process "Core" module was asked to be selected, even if it wasn't upgradeable. |
|
|
|
|
|
Closing issues from 5.0.1 version, because version was already released. |
|