Can somebody bring the light on the following issue - I can't figure out the difference between alfresco workflow model and repository model. Are they different ? Can I use them together, or one inside the other ?
Workflow model deals with the Business Process Modeling(BPM), where you would manage flow of different tasks to user by user. On the other hand there is a 'Content Model' which is independent of workflow model, and it deals with your content types, properties and constraints within the content model. Both are different and independent, however you can use both of them together.
Related
I am using ABP Commercial to implement a custom CRM system. I am looking for an example, a best practice, a library, or even a framework for scoping data according to user IDs and roles.
Simple scoping like just showing entities created by a certain user is fairly straightforward. But what about showing increasingly more broad data based on a hierarchy of user roles.
For example, I might have a basic user role that can only see data created by the user in that role. Then, I might have a manager role that can see his own data and all the data created by the basic users he manages. Contemplating any decent size organization, you can see how this hierarchy might get quite deep.
So can anyone tell me whether there is a facility or module within ABP Commercial or ABP Framework to facilitate this kind of pattern or if there is third party best practice, library, or framework that might work in conjunction with my code to realize this functionality?
In the past I have written my own implementations but I am looking for a DDD or clean architecture based solution.
EDIT
A more specific example of what I'm trying to do is to create an extension of the user class and role class or to add additional entities managed by a domain service that would allow for:
users to have a collection of roles they manage and a collection of specific users they manage, and…
roles to have a collection of other roles they manage (think composite pattern)
These relationships would be used to filter all kinds of queries within my application.
Here are some use cases:
return a list of contacts associated with the clients of my direct reports
return a flattened list of all users managed by me or my reports
return the total revenue of all sales made by users managed by me or my reports
Within the implementation of MDM based on the PIMCORE solution, we wish to segregate data according to user rights. The goal is to restrict access to the attributes of an object according to predefined roles.
The different possibilities were to go through either perspectives or customer views but it is not possible to add more detailed restrictions at the attribute level. The other possibility would be to do specific development in PIMCORE, but this is still a bit expensive.
In your opinion, is there a native way to manage this data segregation in PIMCORE? Or do you have a way to do this on a specific development?
There are the following possibilities:
Custom layouts
Custom Layouts give you the possibility to define different views on data objects for certain users. You can hide certain fields from the admin backend to certain users which is a great way to achieve what you want. The drawback is that this is not suited for "high-security scenarios" as the full data objects are still sent in the background.
So if the data is highly secure it might be readable within the communication streams (https://pimcore.com/docs/6.x/Development_Documentation/Objects/Object_Classes/Class_Settings/Custom_Layouts.html).
Encrypted fields
Maybe you could use encrypted fields to further improve security. A combination of custom layouts and encrypted fields should at least make data unreadable to certain users (https://pimcore.com/docs/6.x/Development_Documentation/Objects/Object_Classes/Data_Types/Others.html). I am not 100% sure, it should be tested.
Workflows
You could use Workflows in order to restrict certain actions on objects depending on the current object state. Workflows have a possibility to fully implement permissions and dissallow certain actions for certain users.
https://pimcore.com/docs/6.x/Development_Documentation/Workflow_Management/Permissions.html
Use Relations
This is probably one of the simplest and best solutions. Create seperate classes for the sensitive data and connect the data objects via Many-To-One or Many-To-Many relationships and restrict access on them. This way you can ensure that certain users never can access or edit the sensitive data.
https://pimcore.com/docs/6.x/Development_Documentation/Objects/Object_Classes/Data_Types/Relation_Types.html
I want my ZF2 Application to import data from many different REST or SOAP Services, which may use different authentication types and so on.
Now I'm basically looking for a structure / architecture how to implement this, maybe some design patterns or ready to use modules if they exist.
Every information could help. I'm also thankful for API docs or tutorials that you provide.
But my main question is: How should be the structure for this kind of "importer"
My Application:
Based on Zend Skeleton Application
Using Doctrine 2
Trying to use all ZF2 Best Practices I can find
Consists of many modules, entities and complex associations in some cases
Entities that I want to import are already working (crud operations, validation, ...)
Apis that I want to use:
Usually E-Commerce stuff, like products, orders, stock keeping
Magento Api (Thinking of Rest)
Shopware and other important Webshops
Ebay Stores
Amazon (I think is going to be the hardest one)
Must have functionality:
I want the api URLs and authentication data to be configurable in my app with doctrine entities
The "Api" Entity should be associated to my "Shop" Entity. Orders or Products that I import or create directly in my App are also associated to my Shop entities. So every Shop/Ebay-Store/Amazon-Store is a "Shop" in my Application. This is already the part I've done.
For example product import should be done directly from my app frontend, I'm thinking of retrieving the api data first and then import them incremtally / step for step
I don't want fat controllers that transform the data into doctrine entities and save them one by one. This way complex associations would become very hard to maintain.
Need a good approach for data transformation and hydration to doctrine entities. Because the data I retrieve from api will usually not have the same structure as my entities. Maybe an attribute that's a property of the "Product" entity in foreign app is excluded into an associated entity in my own application.
Many modules in my application will have entities that should be importable from these apis, so I need a central component that does the job
How would be the best approach for this? I'm not asking for a complete solution, but ideas that fit these requirements.
The Zend HTTP client and its relatives (like Zend OAuth) provides most of the functionality that you need to implement fetching the data from the services.
You can then persist the response in any number of ways, but a schema-less database like Mongo DB makes saving dynamic data much easier. If you are stuck using a relational DB like MySQL then you can either setup an EAV database, or use dynamically generated tables.
Theoretical question. Lets say I build an application for managing clients, products, bills and such. All without a user login.
Is it possible to get multi user (each one with his own clients,products,...) functionality after the main application is done?
Or should I think of the multi user in the first place? How flexible is rails at this part?
thanks in advance
dennym
What you are asking for is a pattern called Multitenant. There are different ways to do it, but none are provided by Rails natively.
You could start with this slide: http://www.slideshare.net/tardate/multitenancy-with-rails
And figure out if you want to do; partitioning based on data, Rbac, model or schema.
There are is one that offers it as a service that says that it is easy to do after you have your application: http://railskits.com/saas/
But in our experience, it was a bit outdated and missing some features that we wanted.
You can also take a look at other gems like: multitenant or act_as_tenant.
We ended up using act_as_tenant and doing it from the beginning.
I'm diving into RBAC while designing new and rather big/complex site.
I'm trying to figure out if to create a task or simply an operation with biz rule.
Now, I've read most if not all existing documentation. The current documentation says that "a task consists of operations". This wiki article says that the different terms are simply naming conventions and the only limitation that exists is structural one - roles must include tasks (or other roles); tasks should include operations (or other tasks) and operations is the atomic term that is not further composed by other entities.
I've also read the relevant sections in the "Agile web dev..." and "Yii cookbook" books - both do not shed further light on this issue (at least as seen through my glasses).
Lets go to my example where I'll present the question. Actually, lets use an example similar to that demonstrated in most of the documentation resources mentioned above: Lets say I have a blog post and I want/need to have its author be able to "update own post". Now, why should this be a task as commonly demonstrated in the documentation resources and not an operation with a biz rule?
I think that the question above reveals the inclear definition of a "task" (in the RBAC context of course).
Please help me distill a better definition for an RBAC task.
EDIT:
I was suggested the following definitions of the mentioned terms that help conceptualize them in a useful way. In short and in its simplest form: operations are the basic building blocks. They are the material developers work with and only them. Developers compose tasks of and on top of operations. Roles are composed of tasks, like a set of tasks. Roles and tasks are what the site administrators should play with - assign and revoke to users but not operations.
That's a nice way to look and grasp those entities (roles, tasks and operations).
Do you have another option to conceptualize differently? Any comments will be appreciated.
TIA!
Boaz.
I'd say the same as you did in your question edit. A task is simply a composition of operations a user can do that have something in common. So you have for example operations oList, oView, oCreate and oUpdate these are the operation developer assigns to controller actions for access control, where the first two are only read- and the second two have write access to data (that's what they have in common). So you now want to combine those to tasks tInspect and tManage which both hold 2 operations, the first one can list and view and the second one can create and update. Optionally you could make tInspect a sub-task of tManage so a user that has tManage can list, view, update and create but normally you just give his role both tasks.
Regarding the classification of role -> task -> operation, they are essentially the same thing, as you can see in the code they are of class CAuthItem. We name them differently mainly from user point of view.
Operations are only used by developers and they represent the finest level of permission.
Tasks are built on top of operations by developers. They represent the basic building units to be used by RBAC administrators.
Roles are built on top of tasks by administrators and may be assigned to users or user groups.
The above is a recommendation, not requirement. In general, administrators can only see tasks and roles, while developers only care about operations and tasks.
Check this out : http://www.yiiframework.com/forum/index.php/topic/2313-rbac-confusion/page_p_16035#entry16035
if there are two user
1)admin
2)user
so we set role updatePost for update page.
and admin is parent of updatePost so admin can update.
user have updateOwnPost permission.updateOwnPost is parent of updatePost with bizrule.so if bizrule satisfy he can update