Description of problem: Currently projects can be obsolete or read-only. Read only should be adapted to act more like "Archive". When a user archives a project: - It becomes read-only - It is only viewable in the "Archived" project list on the maintainers dashboard - It has the option to be included in global TM or in copytrans There is one use-case I know of where read-only is still needed, so some thought about how to deal with this will be needed.
Does it means that: 1. Read-only should be renamed as "Archive" 2. Maintainer can changed Obsolete and Active to and from "Archive". 3. Project search page should have a toggle "Show archived project/version". 4. User can search archived project/version when "Show archived project/version" is on 5. Non-maintainer can read/pull/download translations to archived project/version 6. Non-maintainer cannot edit/push/upload translations to archived project/version 7. Translations of archived project/version should be copied by copytrans 8. Translations of archived project/version should be appear in TM.
1. Basically 2. Obsolete effectively becomes deleted, which… is deleted, with no further access, except maybe admins or with a 7 day grace period for maintainers. Archived projects can be "unarchived". 3. Project search will not show archived/deleted projects. No filters will address this. 4. Users can't search archived projects. But they can view them in their dashboard. 5. Non-maintainers will only be able to access archived projects through direct links, usually from TM if that is available. 6. Changes cannot be made to an archived project, they will be read-only until unarchived. 7. The details of how copytrans works with archived projects will need to be discussed. 8. The maintainer can decide whether archived projects are available to the TM with the default being yes. I am happy to have a discussion about this point, but using archived projects in the TM seems to be one of the main reason for archiving instead of deleting. Sean, maybe you could help address point #7?
(In reply to Luke Brooker from comment #2) > 4. Users can't search archived projects. But they can view them in their > dashboard. Does that mean: a. It will appear in the dashboard as long as it is not "expired" b. It will appear in the dashboard as long as he/she is the maintainer. > 5. Non-maintainers will only be able to access archived projects through > direct links, usually from TM if that is available. I am quite sure people will still use it for translation freeze, that is, archived project/version might still be used for project build.
4a. Archived projects will never be considered "expired". Deleted project will never show in the dashboard, if possible they could only be reinstated via a link in an email. 4b. It will only show they are a maintainer and it would need to be under a "Archived" tab/filter 5. So that is covered by my answer?
(In reply to Luke Brooker from comment #2) > 1. Basically > 2. Obsolete effectively becomes deleted, which… is deleted, with no further > access, except maybe admins or with a 7 day grace period for maintainers. Let's keep the problem of permanent deletion separate from this archiving RFE. > Archived projects can be "unarchived". > 3. Project search will not show archived/deleted projects. No filters will > address this. No filters... what? > 4. Users can't search archived projects. But they can view them in their > dashboard. > 5. Non-maintainers will only be able to access archived projects through > direct links, usually from TM if that is available. > 6. Changes cannot be made to an archived project, they will be read-only > until unarchived. > 7. The details of how copytrans works with archived projects will need to be > discussed. CopyTrans reuses translations in read-only projects, so it sounds like it should reuse translations in archived projects. Basically, if it's visible in the TM, it should be eligible for CopyTrans. > 8. The maintainer can decide whether archived projects are available to the > TM with the default being yes. I am happy to have a discussion about this > point, but using archived projects in the TM seems to be one of the main > reason for archiving instead of deleting. So why make it a choice? Right now, read-only projects are part of TM. If you don't want it in TM, you should delete the project. > Sean, maybe you could help address point #7?
- Sure - Yeah no filters for global project search, only on the dashboard if you are the maintainer of the project. If you archive a project, it should be public facing, except when it needs to be linked from a TM. - That's what I thought, so it could be included in a setting like "Include in CopyTrans and Translation Memory?" - Because they may want to keep it there to for future reference but don't want it stuffing up the TM. On thinking about this, maybe the option to to include in CopyTrans/TM should be part of the project settings regardless of it's state?
Please use Bugzilla's reply feature when replying; it's too hard to track the conversation otherwise. (In reply to Luke Brooker from comment #6) >> Let's keep the problem of permanent deletion separate from this >> archiving RFE. > - Sure >>> 3. Project search will not show archived/deleted projects. No filters will >>> address this. >> No filters... what? > - Yeah no filters for global project search, only on the dashboard if you > are the maintainer of the project. If you archive a project, it should be > public facing, except when it needs to be linked from a TM. I don't understand that paragraph. Actually, I'm still trying to work out what the sentence "No filters will address this." actually means. What sort of filters are you talking about? Lucene filters would actually be a pretty good way of hiding archived projects from project search, but I don't think that's what you meant. >> CopyTrans reuses translations in read-only projects, so it sounds like it >> should reuse translations in archived projects. Basically, if it's visible >> in the TM, it should be eligible for CopyTrans. > - That's what I thought, so it could be included in a setting like "Include > in CopyTrans and Translation Memory?" If it is a global (server-wide) fact that this content should not be in TM, the content should not be in Zanata either. >> So why make it a choice? Right now, read-only projects are part of TM. >> If you don't want it in TM, you should delete the project. > - Because they may want to keep it there to for future reference but don't > want it stuffing up the TM. If it's not in the TM, the only way to see it would be for the project maintainer to visit the archived project directly and launch the read-only editor. It's not worth the complexity (and disk space) for such a narrow use case. If the project maintainer wants to refer to it but keep it out of TM, he or she should download the contents (PO, TMX) before deleting. > On thinking about this, maybe the option to to > include in CopyTrans/TM should be part of the project settings regardless of > it's state? I think the problem of TM subsets would be better addressed by letting translators/PMs choose which projects will be visible in TM *for that translator/project*, rather than implementing features which encourage keeping suspect translations around clogging up the database.
(In reply to Luke Brooker from comment #4) > 5. So that is covered by my answer? What I meant to say was: Client should be able to pull from archived project-version. If you can see it, you should be able to use it.
(In reply to Ding-Yi Chen from comment #8) > (In reply to Luke Brooker from comment #4) > > 5. So that is covered by my answer? > What I meant to say was: > > Client should be able to pull from archived project-version. > If you can see it, you should be able to use it. I guess this would be considered read-only so it should be ok? For this feature I will make sure I confirm our specifications with translator and maintainers before going ahead.
It seems that I was confused. "Archive" seems to be the new name of old "Obsolete".
Bumping to high - this request is becoming more frequent
*** Bug 876807 has been marked as a duplicate of this bug. ***
1. Allowing project maintainers to archive projects 2. Making the id available for reuse 2.1 Allowing project maintainers to change project and version id 3. When restoring the project or version, system should warn the maintainer that new id is needed for the project, only if the previous id is taken.
Migrated; check JIRA for bug status: http://zanata.atlassian.net/browse/ZNTA-302