You can publish catalogs directly from PARTproject various functions for this can be found under the context menu commands Version management [Versioning system] and Publishing [Publication].
Publishing happens in 3 basic steps: Upload changes/Execute mapping, QA publishing and Live publishing (where publishing does not have to be necessarily performed immediately after the upload of changes, however, the up-to-dateness of mappings should be ensured before publishing).
Upload changes / perform ERP mapping:
Check ERP mapping [Check ERP-Mapping] dialog:
As soon as the Upload changed files in directories/projects to the server [Upload changed files in directories / projects to the server] command is executed under the Version management [Versioning system] context menu command, the Check ERP mapping [Check ERP-Mapping] dialog box opens automatically (provided that 1. relevant changes have been made to the data and 2. the Check ERP mapping when uploading [Check ERP-Mapping on upload] option is activated for the catalog). Please also refer to the notes at the beginning of Section 6.10.2.1.1, “ Check ERP mapping (Add ERP mapping... and Edit ERP mapping...) [Catalog modeling]”.
Click on to load the published catalog statuses and select the most recent one. Please note: Especially if Remember selection [Save selection] is activated, you will still have to search for a published catalog status (live publishing) again and select the latest one.
Then perform ERP Mapping for the entire catalog or changed projects. Skipping would make sense only in very limited number of cases, because if this dialog occurs, then the files selected for uploading in fact contain at least one change requiring a new updated mapping.
This dialog is shown if tab/tac files have been changed (-> new tab version), but the change in itself does not require a mapping (e.g. new table row added).
The background is that the tab versions have to be updated in the mapping, if the respective table is already part of the (current) mapping, to ensure that there will not occur any problems during Live Publishing.
If you know whether the date displayed in the dialog corresponds to the last live publication, confirm with , otherwise click . If in doubt, always confirm with .
To check whether something has been forgotten to verify or whether the tab versions match the local status, execute the context menu command Add ERP mapping under Publishing [Publication] after updating the catalog. This performs the mapping for the current status.
Mappings that have already been verified and are already available are not overwritten. This means that if every user has made and verified their mappings correctly, there should be nothing more to verify manually at this point. Only if something has been forgotten or the tab versions do not match the local status will there again be mappings with the "to be checked [to check] " status that still need to be verified.
This step is not necessary, but it allows you to determine whether there are any problems with the mapping without performing a live publishing and to solve them before publishing.
The local current state of the user is separately saved as new QA state (in the SVN Server Publishing Branch).
![[Important]](https://webapi.partcommunity.com/service/help/latest/pages/en/ecatalogsolutions/doc/images/important.png)
Important NOT the state on the server ("Trunk") is primarily used.
For Details see Section 6.10.5, “ Generate QA status.. | Publish live stand.. ”, in particular Fig. „SVN Server TRUNK and SVN Server Publishing BRANCH“.
If there are local changes that are not uploaded to the server (context menu command Upload changed files in directories/projects to the server [Upload changed files in directories / projects to the server] ), these will still become part of the QA publication for the above reason.
-> If the user performing a QA Publishing updates the entire catalog before and has no not-updated local changes anymore, then the QA state will become a copy of the current server state (current trunk). In most cases this is the best approach. The mapping file existing at the time of QA Publishing is the file which then later will be used for the Live Publishing.
Live publishing: The last QA publishing process carried out is transferred as a live status. This includes checking the ERP mapping, transferring the data to the live portal and CIP generation.
If a user obtains write permission for a directory, the mapping.json file is also automatically updated. In the meantime, another user can work on a different directory and when the changes are uploaded, the mapping file is also adjusted and uploaded.
In fact, the first user has no up-to-date mapping file anymore, what however is not a problem, as long as the paths of the single mappings do not overlap. (And overlappings should not happen, as users cannot get writing permissions for the same directory.)
It is especially important that at the time of QA Publishing the mapping file matches the current (local) state. (A problem would be, for example, to have the current mapping file locally, but only to update a part of the remaining files (e.g. single directories).
So if all changes (included those from other users) shall be published, then you should update the entire catalog in any case before, in order to have them locally.
The mapping process is the same for partial publishing, at least if you create the mapping every time you check in. If you create the mapping once before publishing, you must use the context menu to execute the command Add ERP mapping for partial publishing [Add ERP mapping for partial publication....]... on the directory/directories that are to be published. Further details can be found at Section 6.10.6, “Partial Publication ”.
Icons (
) signalize the publication state. If certain
published projects (directories) will be visible in end media or not, can be
controlled by context menu command:For details see Section 6.10.3, “Publication mark ”.
The publication status shows the potential visibility of projects. Whether projects are actually visible in output media is determined by the interaction of several factors. See Section 6.10.4, “ Case differentiation concerning project visibility in end media”.
The status of the publishing marker (set or removed) is checked into SVN when the context menu command Check in directories/projects (give up editing rights) [Check in directories / projects (set read-only)] is executed, as the information is stored in the respective project files.
The current status of generation and publication can be viewed at any time.
On this see Section 6.10.7, “Info dialogs: Messages... | Publication status | Publication history | Log file ”.
The e-mail notification contains a log file with detailed generation/publication steps.
On this see Section 6.10.7.4, “Log file”.
When generating/publishing a catalog, release notes [Release Notes] must be entered, which are displayed in PARTdataManager (catalog context menu) and PARTadmin (category online catalog update, catalog context menu).