nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Delete from WA not Staging

Linio

Hi,

I have an issue with my workareas as i have multiple areas submitting to the same staging, but where files are not shared (basically users on Workarea1 works on file1.htm for example and users on Workarea2 are working on file2.htm).

Files never goes from staging to workareas thus in Workarea1 there is only the file1.htm and on Workarea2 only the file2.htm.

Yesterday a user accidentaly got the latest version of the staging putting the files from all other workareas on his workarea.

I need to have those files deleted but not deleted into staging. Knowing than there is an automatic workflow on the submittion which will delete my files from my Content Server on Production, i was wondering if there is a way to delete (and not having the X red file on my workarea) without having this deletion propagated to my staging?

Thanks

Find more posts tagged with

Comments

nipper

The news is bad and will get worse.

No you cannot do what you want.

A bigger issue is that you are using TS in a way I have seen before and invariably this causes larger issues (similar to what you see but with conflicts/collisions on submits). I have seen companies delete their branch and recreate it again to make it work (wrong).

The staging area is your branch, each workarea *should* be mostly equal to (or completely) the stagind area. When someone makes workareas continually diverage from the staging area, problems will happen.

Either get your workareas in sync with Staging or break this branch into mulitple branches. I tend to do the latter.

Linio

I would nipper, i would, but then again if my client was using the software (and all other softwares for that matter) correctly, i won't be here trying to resolve such... problems.

More than that, My client being a "big" client, it would be nearly impossible to change the system the way it was done, maybe 200 workareas, as many deployments...

What strikes me though is that if at one point it is possible to have those files not shown in the Workarea, i don't understand why we cannot manage to go back to this kind of state...

Adam Stoller

I would nipper, i would, but then again if my client was using the software (and all other softwares for that matter) correctly, i won't be here trying to resolve such... problems.

More than that, My client being a "big" client, it would be nearly impossible to change the system the way it was done, maybe 200 workareas, as many deployments...

What strikes me though is that if at one point it is possible to have those files not shown in the Workarea, i don't understand why we cannot manage to go back to this kind of state...

You can get back to that state - it's just that it is a very "fragile" (and "incorrect") state.

If you delete the files in the one workarea that aren't "supposed" to be there - just make sure you never submit those deletions.
Alternatively - create yet-another workarea against the INITIAL edition - and copy the files you want into it - then delete the old workarea.

Again - this is incorrect usage of the application and destined for problems - it would be far better to make the effort of [re-] educating the customer on how the application works and is supposed to be used - so that the situation can be fixed to a "working" one - but that's your headache...

Linio

If i'm deleting the files, it will still show them with the Red Cross.
The only viable solution seems to recreate a workarea.

Concerning the reeducation, since i'm not paid for such thing, my hands are basically tied.

The joys of subcontracting...

Thanks for the heads'up anyway.

nipper

Concerning the reeducation, since i'm not paid for such thing, my hands are basically tied.

The joys of subcontracting...

Basically, they are screwed. You certainly *should* document the this behavior and let someone (who may not care) know the issues they may face down the road. I have seen people try this multiple times. Every one of them has ended poorly. Sometimes extremely poorly.

dlsoderberg

I used to work in a similar environment as well...

If you want to remove the file(s) from the WORKAREA that shouldn't have them, be sure that your other WORKAREA has the correct version of the file in it. Delete the file from the incorrect WORKAREA and submit it using the OOTB default Submit workflow. (If you don't have access to this, can you get it?) Then submit the file from the proper WORKAREA and you will be back to the way you were. The WORKAREAs will contain the proper files and STAGING will be complete. This doesn't by any means validate that setup, but will at least get you back to the original state.

LMX

I'm with Ghoti on this one... recreate the workarea based on INITIAL, and only copy down the files you want. This can be a common problem you will encounter... how do you prevent a user from accessing other files in staging and editing them? You could write the world's longest submit.cfg file and lock down directories based on workarea/users, but it will also prove to be a mangement nightmare.

Easiest solution: remove all instances of "get latest" in ContentCenter menus Smiley Happy

Whomever architected your solution should be shot.

Good luck, Linio.

nipper

Whom ever architected your solution should be shot.

Gotta love that attitude. LMX you are certainly someone I could work with. Smiley Very Happy

LMX

Gotta love that attitude. LMX you are certainly someone I could work with.

I can deal with poor programming, bad/limitted infrastructure and difficult clients... but missing the boat on the most fundamental of TeamSite architectural decisions makes homer something something...

Linio

Easiest solution: remove all instances of "get latest" in ContentCenter menus

Whomever architected your solution should be shot.

Good luck, Linio.

Actually that's now the request that I have...
I have to see how this can be managed, because it is only the case for "some" workareas, the get latest function should be ok for the other ones.