View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0009155 | MMW v4 | Framework: Scripts/Extensions | public | 2012-02-19 20:33 | 2012-04-26 23:36 |
Reporter | zvezdan | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Target Version | 4.0.5 | Fixed in Version | 4.0.5 | ||
Summary | 0009155: RelatedObjectID is incorrect for some folders | ||||
Description | RelatedObjectID is incorrect for Artist and Album sub-nodes of Genre, Conductor and Producer folders - inside of the Genre folder they return the same ID as it is its parent Genre ID, inside of the Conductor and Producer folders the Album ID returns -1. RelatedObjectID is also incorrect for nodes in the Classification folder, i.e. for sub-nodes of Tempo, Mood, Occasion and Quality. | ||||
Tags | No tags attached. | ||||
Fixed in build | 1480 | ||||
related to | 0011077 | new | SQL queries as node properties for built-in and custom nodes needed |
|
Problem is that this single ID can't cover all the possible cases that can happen in MM (i.e. all the hierarchy of nodes). Also the internal representation of IDs might be different that scripters would expect. So I wonder, would it help if we give scripters access to the SQL used by given nodes? It probably wouldn't be easy to implement, I just wonder whether this is what is needed. Resolving until we get more feedback... |
|
I am not asking for full access to the SQL, I just want from you to be consistent. The Album node which is a sub-node of the Artist folder correctly returns ID of the Album. Same state for Album nodes within many another folders (Album Artist, Artist & Album Artist, Author, Composer), but it is incorrect within Genre, Conductor and Producer. Also, Artist node within Genre folder is incorrect, it returns ID of the Genre which is even worse than if it returns -1. You are making high science about that issue as if I requested that you implement the space shuttle into the program. There is not to many possible cases which you should cover, beside of those that you already have covered - you should just implement those that I have mentioned: Genre, Conductor, Producer and Classification sub-nodes. I really don't understand in which interest is that you have the inconsistent program. |
|
There really is a reason why it's currently implemented so. Ludek, could you please review whether we can modify it easily without too complex changes? |
|
Fixed in build 1600 and merged into 4.0.4.1480 |
|
Verified 1484 |