StrataFrame Forum » StrataFrame Application Framework - V1 » Issues » 1.6.5 - Update security tables

RE: 1.6.5 - Update security tables

Ivan George Borges — Thu, 14 Aug 2008 18:48:17 GMT

Entendi, faz sentido desde o início. Eles provavelmente anotaram sua observação logo no primeiro post, e provavelmente vai ser revisto para o futuro...

Eu só queria me certificar de que você não estava adicionando as estruturas várias vezes em função de alguma alteração no seu projeto de segurança. Mas ficou claro, você está certo.

Valeu. ;)

1.6.5 - Update security tables

Rogerio Mauri — Thu, 14 Aug 2008 18:48:17 GMT

Olá...

Which the correct procedure for conversion of security tables? Because I had problems after the update of the version.

For example:

1) If I to exclude tables of security of the DDT, the installing package it also excludes in the base destination.

2) If I to recharge tables, the update of the DDT duplicates and gives errors.

RE: 1.6.5 - Update security tables

Rogerio Mauri — Thu, 14 Aug 2008 18:23:48 GMT

Ivan... Boa Noite...

No lançamento da versão 1.6.5 houve uma alteração na tabela 'Users' com a inclusão do campo 'us_DisplayName'. Daí, a necessidade de reimportação das tabelas do módulo de segurança.

Existe, de fato, a possibilidade de exclusão, limpeza do histórico e nova importação das tabelas, no entanto, em algumas situações, criamos relacionamentos entre a tabela "users" e outras tabelas de cadastro para vincular o código do usuário autenticado ao registro adicionado. Então, se excluo as tabelas, depois preciso recriar todos os relacionamentos.

Considerando que o DDT permite nova importação das tabelas de segurança, mesmo estando elas já importadas, seria conveniente então criticar esse processo não permitindo essa situação, pois do jeito que está (faça você mesmo o teste) a rotina indicada pelo DDT como 'update' na verdade duplica as tabelas de segurança e ainda gera outros erros. Não sendo possível o 'update' de fato, sugiro criticar o processo de importação, quando este já ocorreu, com uma mensagem de erro tipo 'Se deseja fazer nova importação das tabelas de segurança, exclua manualmente as existentes no projeto e limpe o histórico de atualização'. Nesse caso, um alerta também poderia anunciar que eventuais relacionamentos criados com essas tabelas seriam perdidos.

Abraços.

RE: 1.6.5 - Update security tables

Ivan George Borges — Thu, 14 Aug 2008 07:18:17 GMT

Olá Rogério.

Just out of curiosity... why are you running the wizard and adding the security tables into your DDT project over and over again? Once the structures are added, you don't need to it again. If you want to do it though, delete them first, and go to the History and delete them from there too. Then you can add again. But I don't know why you need to do that every time.

If you add Permissions, Users, Roles, etc into your Security project and want to deploy them, you don't need to add the structures again. This is done through the Deployment Data node on the DDT.

Abraços.

RE: 1.6.5 - Update security tables

Rogerio Mauri — Wed, 13 Aug 2008 19:51:23 GMT

This problem continues in version 1.6.6.:crying:

RE: 1.6.5 - Update security tables

Rogerio Mauri — Sun, 09 Mar 2008 21:48:02 GMT

Ok... I suggest then only the correction in the DDT to prevent the duplicity in the assistant of update of security tables.

RE: 1.6.5 - Update security tables

Trent L. Taylor — Sun, 09 Mar 2008 21:08:24 GMT

We have started implementing the auditing (which will be fully released before long). So even though these tables are being imported, they aren't necessarily being used yet (through the 1.6.5 release). But having them there will not hurt anything. That is why you see the SFSAuditEvents table in the imported package file, but we have not yet released the framework side that allows you to interact with that table. Hope that makes sense. :)

RE: 1.6.5 - Update security tables

Rogerio Mauri — Sun, 09 Mar 2008 19:09:18 GMT

Olá...

Ok... The suggestion is correct. However, it verifies the option of update, without removal of tables. It is really duplicating new tables added in the last version (Audits).

The step of cleanness of the description of adaptations is really very important.

RE: 1.6.5 - Update security tables

Trent L. Taylor — Sun, 09 Mar 2008 11:04:03 GMT

Hmmm...I am not sure out you ended up with two tables of the same name...I will see if I can reproduce. The easiest thing would be the following though:

Manually remove the SFS tables and views
Manually remove the Security related Deployment Data items in the Deployment Data section
Now...and this is an important step...select the Object Name History and delete the SFS table name deletions from the Object Name History so once we import them back in they will not be deleted
Now, Select the Profile -> Add Security Tables menu
Once this is done, click on the Deployment Data node and then click the Deployment Data Package Wizard button
Then go through the standard motion of bringing in the Security data for the desired project.

When you rebuild your package, you should be good to go. Since we now have the Data Verification process, any tables accidentally left in the Object Name History that could cause problems will be brought to your attention. If you get a clean bill of health once built, you are good to go.

RE: 1.6.5 - Update security tables

Rogerio Mauri — Sat, 08 Mar 2008 07:34:15 GMT

Image...