Hemi Content Stream - Technical changes

This will be a separate project forked from the MVC (newui-master) branch

For the development we will create a new Controller for each section, but we will reuse the old code as much as possible (mostly including/extending, limited copying). We can remove code that is not needed but it is not recommended as it may not be required for now and ends up needed in the future. Extra feature will be to add new menu and routes that are handling the requests to the system.

We will create a copy of hub_alpha, (hub_content, for example) and we will add all changes there as needed. For the menu and for the access. For client (and all other connected to it tables), there is a feature in this document that explains how it will be handled.

For Content users:

When a content users logs in Hemi we are to check his access. Standard SSO check plus if the user has the flag for Content User. If he is a content user we need the alpha to forward him to the content url for home. This will be a separate URL as it is a separate project.

Content screens:

For this project we will have a simplified menu with Products / Imports / Exports. For Products the user will be able to see all items he has access to and change their information. We will also have a list of all Rejected item changes, as it will be visible to the user. For imports we will have a changed version of the current one with more restrictions applied to it based on the requirements from product. For exports it is the same.We can have predefined ones (all rejected products)

Products screen:

We will be showing all the information from item/item_account/item_account_specfic tables, that is marked to be used by the specific content user group, for the specific item. The content user will be able to see and change all of the information there. We are then to keep these changes in a separate table for each field (content_changes_item/content_changes_item_account and etc.) We make a copy there for these products with the new information.

After that we are to save all differences in table content_changes. In it we will store the original and the new value as well as the table_record_id (item or item_account or itemaccount{specific}). And we will also store the id of the item, because it will be needed. We will need the status of the change. This will be done to keep the new data visible for the content user (what they have entered) and for easier identification of the changes when handling them.

If there is a record in the content_changes tables (the counter parts of the item/item_account and etc.), the content user will see the information from them and not from the original ones. We can try to do this in the query, but if it becomes too heavy, we are to load the data from the regular tables and then load all the info from the content tables to overwrite them if applicable.

If a new change happens to the same field, while the previous one is still pending. We are to remove the old one and create a new record in content_changes table. This is to be able to show the hemi user that this change is no longer available without checking for the information in it. (Example: If the content user changes the title, then changes it again, before the regular user manages to access it, we are to update the change and remove the previous one. Only keeping the latest change of this title)

The first tab will be Item with the information from the item table. Then every other tab will be combined item_account and itemaccount{specifc} table, for every item_account record. For name of the tab we will be using the Account Name.

The fields from the item tables will be shown only for the ones marked with an option in form_field that when checked the field will be shown in the content screens.The product team will able to go over and set up and we will use that setup as an install afterwards.

Rejected screen:

In the rejected screen we are to be using the content_changes. In which we are to show all rejections (status rejected) and the comment for the rejection. We can show the current value in the specific field so that the content user is aware of the rejection and what was kept.

Imports screen & functionality:

We need to only restrict to what is required. We are applying the changes to match the scope. Only restrict to one type of Import, a new one (content items).

<v1.1> When executing the specific type of import any updates are to follow the logic for the content management functionality (meaning insert/update the values in the content_changes tables and etc.) and it should not do any changes to the item/item_account tables. It is just another way of changing updating the values instead of the interface</v1.1>

Exports screen:

We need to only restrict to what is required. We will make it in one screen and have the option for the predefined layouts and add the options in the interface for the content user to choose. All other options will be handled in the alpha with flags, that mark them available for the content use.

Changes in regular Hemi:

In the alpha project we will add a field to item that is for which content user group is handling it.

Review Screens

We will also need a new screen for approval/rejection of changes (review). This can be done in two places.

In bulk table view - the link to this will be in the menu.

And in the item/item_account/itemaccount{specific} single record view screens we need to add a button that leads to the Single Item view screen with the changes. Only if any changes for this item are present.

In bulk table view

For bulk we will have a table of every field that has a change. We will be using the content_changes table for this view. The user can mark the changes and accept/reject in bulk by checkboxes, that are at the first column of the table. The options for bulk are to be displayed in the bar for bulk actions.

Upon rejection а popup for a comment should appear and the comment is saved the same for all rejections.

Upon acceptance we will delete the records from the content changes, update the fields in the item/item_account tables accordingly and mark as update to MP. A confirmation popup should appear that explains this. All changes must be in the history tables.

If all changes to an item have been approved we are to delete the records in content_change_item/content_changes_item_account accordingly. If any change is rejected we are not going to touch these tables.

In this view as a table action we should also add the option to accept/reject a single change.

The SKU (this should be an enum that shows the SKU from the id of the item that is stored in the table) that will be displayed should be a link to the Single Item View of the changes.

Single Item view:

For single item we can show all changes in an UI displaying old/new next to one another and have an accept/reject button next to each change.We will be using the content_changes table for this view. And the functionality will be the same as in the bulk (reject requests a comment, accept deletes if everything is ok and marks and etc.). We can have a button reject all/accept all that can be done to everything. The changes should be split into tabs for every table as per the product scope.

Users

For the users. We will need to change the information for the users to be handled from the hub_alpha users tables from now on. We will also add the option for (content_user). If this is marked this user is treated as a content user  and he only has access to the content stream and not the regular Hemi. When saving, the user details that we filled in the form from the interface, and if the user is marked as a content_user (the checkbox is clicked to true/1) we are to copy his record in the hub_content table and create the link to client/client_user/threecolts_organizaiton (as per the sso). We can select all that information upon saving. This will be handled one by one so it is not a problem.