Reorganizing History Data

[RalphM]

Ok, so I wait 'til after Undo is (un)done....

[RalphM]

Since there was talk about multiuser environments in another thread, I thought it was appropriate to

*BUMP*

this one again...

[admin]

Since there was talk about multiuser environments in another thread, I thought it was appropriate to

*BUMP*

this one again...

You mean only because my president resigns I start reorganizing history data? Not before the WM is finished...

[RalphM]

Well, it was worth a try, so I'll bump it again after the WM?!
...and yep, you're right it might fit perfectly with a general reorganizational mood in Germany...

[RalphM]

*Bump* again after 1.5yrs

I still think this wish - if implemented - would attract more companies to have a closer look at XY, and with the recent additions to the catalog it might be the right time to do it...

[admin]

*Bump* again after 1.5yrs

I still think this wish - if implemented - would attract more companies to have a closer look at XY, and with the recent additions to the catalog it might be the right time to do it...

You are referring to this: http://www.xyplorer.com/xyfc/viewtopic. ... 985#p30985

Yes, it has certainly come nearer due to the recent additions, and it is on my to do list. But it would still be quite some work, and what makes you think that "it would attract more companies" -- would your company buy it? From my experience companies are very interested in MUT (multi-user tagging) which is also on my list.

[RalphM]

Yep, that's the one I was referring to, aka "Cascading Catalog".

I can't promise my company would buy it, but I would definitely feel more confident to propose it.

[admin]

Yep, that's the one I was referring to, aka "Cascading Catalog".

I can't promise my company would buy it, but I would definitely feel more confident to propose it.

I had some spare time today which I used for relaxed contemplation and the result is: Yeah, I can do that pretty quickly. Next week it should be there.

[RalphM]

Great, looking forward to see this evolve.

[admin]

Great, looking forward to see this evolve.

Question:
Should the merged data be stored locally together with the parent catalog? Then it would even be possible to allow the user to edit the merged data without overwriting the original source. Note that at any point it is possible to unmerge any merged data, or to reload/refresh them from the server (both actions would mean a terminal loss of any edits, of course).

A big advantage of storing a (maybe editable) copy the merged data locally would be that on restarting XY the next day, they would be right there without the need to re-load them from the server (which might be offline...). And you could take them home on a stick.

[RalphM]

I see your point, but how would the user (or the local copy) know of any changes made to the server version of the company- or department-wide part of the catalog.
I think that's the main point behind it, to change the server-based parts of the catalog and have them automatically reloaded on the next startup of the users XY.

[admin]

I see your point, but how would the user (or the local copy) know of any changes made to the server version of the company- or department-wide part of the catalog.
I think that's the main point behind it, to change the server-based parts of the catalog and have them automatically reloaded on the next startup of the users XY.

OK. So if it is not stored locally, then I should probably disallow and editing/repositioning of merged items simply because it would be lost on next start. Right?

[Stefan]

Hi, i like the idea and think i would agree as is it developed.

I think i will not use this feature for that department hierarchy thinggy (maybe) but for more private use like:

( Note category names are the same as catalog names for merging)
a

Code: Select all

=Merged Catalogs at work=
  Common.cat
     common category
         common item
         common item
         common item
  Work.cat
     work category
         work item
         work item
  Temp.cat
     project category
          project item

and 

=Merged Catalogs at home=
  Common.cat
     common category
         common item
         common item
         common item
  Home.cat
     home category
         home item
         home item
         home item

So if i want to edit one of the merged catalogs
i had to load and edit them alone,
then switch to load the merged cats (? ;-)) again?
No big issue maybe, just want to mention this behavior before dev is done.
But maybe there could be a switch, as like: if there is an item called "editing disabled" then don't allow modifying ?)


And i saw an issue: what happens if two items in different catalogs have the same name?

Code: Select all

 First.cat
   some item
 Second.cat
   some item

 Merged Cat
   some item
   some item

Just some thought.

.

[admin]

You will be able to reload a merged catalog. To avoid too much switching simply edit the merged catalog in a different XY instance, then reload.

Items of same name will not overwrite each other. Categories of same name are merged under this name.

[RalphM]

OK. So if it is not stored locally, then I should probably disallow and editing/repositioning of merged items simply because it would be lost on next start. Right?

Unless you enable the user at least to see that some items in his merged catalog are "dirty" and provide a way to reload the current server version?!