roles addition

[MercedesAMG1]

it would be nice if alanning:roles package could be integrated, then front end can be open or available to non-registered users but registered users could be given access to different collections and fields based on role

[radiegtya]

I'll consider this in the next update.

Thanks

[radiegtya]

Hi @MercedesAMG1 , for now if you want to use roles package. You can use the meteoris role preview version. Just update to the latest meteoris version to try it. then access this following urls:

1. Create your group role using this link http://localhost:3000/mugenRoleGroups
2. Create your collection role using this link (this is will be generated automatically when meteoris generate a new collection). http://localhost:3000/mugenRoleCollections
3. Lastly You can add some action for every collections for example if you have path like this. posts/index it means that your collection are "posts" and your action are "index". meteoris will check whether it is able to be accessed or not according to the group you set. the default group will be "*", "@", and "admin".

"*" means anonymous user "@" means logged in user "admin" means your administrator

btw anonymous user will be granted automatically action "index" and "view". Of course You can also change it on the mugenRoleGroups menu.

Just try it, and tell me if you have any problem.

Thanks

[MercedesAMG1]

Ok, so the workflow should be

1) create some users 2) create some collections with relationships 3) create some RoleGroups beyond *, @ and admin - (i.e. "employee") 4) create some RoleCollections - I don't understand your point 2 which seems a bit circular ... Do you create the collections before mugenRoleCollections or after? 5) create the actions if and as needed "index" "view" "update" "insert"

Thanks Peter

[radiegtya]

point 4 means that mugen will auto insert into "mugenRoleCollections" table when You are generating code using mugen. Or you can manually insert your collection using "mugen role collection" menu.

Btw your workflow are correct.

Thanks

[MercedesAMG1]

I got the roles aspect to work on your posts collection

added posts/index posts/update posts/insert posts/remove and posts/search

they all worked perfectly so I would assume the roles function will work just fine on other collections added

does this mean you will only use this process for roles or will you be integrating alanning:roles from meteor

I also noticed a package called ongoworks:security. Do you think that would work as well or in conjunction with meteoris or not really needed as can define roles actions one by one

Peter

On Wed, Jan 7, 2015 at 7:14 PM, Ega Wachid Radiegtya < notifications@github.com> wrote:

point 4 means that mugen will auto insert into "mugenRoleCollections" table when You are generating code using mugen. Or you can manually insert your collection using "mugen role collection" menu.

Btw your workflow are correct.

Thanks

— Reply to this email directly or view it on GitHub https://github.com/radiegtya/meteoris/issues/20#issuecomment-69126362.

_Peter Gerwing _petergerwing@gmail.com petergerwing@gmail.com 403-507-6299 _Box 4125, _Olds, Alberta, Canada T4H 1P7

[radiegtya]

of course you can add "post/whateverActions" like alanning:roles, for example: posts/upsert, posts/viewAllMyGirlFriend, posts/favourite etc. So I don't think meteoris need to be integrated with alanning:roles, because all what alanning:roles can do, meteoris did. And I'd like meteoris developer to focus on code, just relax about roles without adding single code and just using roles UI easily.

about ongoworks:security I'll try to studying it first. :)

Thanks

[MercedesAMG1]

for the mugen relationship to work each new field can relate to a different collection and the corresponding "exact" spelling of the field name in that relational collection.

I relating one field to the users collection and mugen did not like profile.name, especially the "." but profilename didn't work either(this is on the generation of the mugen files (lib/collection/filename.js)

Another Question:

I know I could remove the @ group because it it is available for deletion How could I remove the star(*)anonymous user?

Or is there a way to say no access to index and view some other way. I am not sure if you are using allow/deny or not.

Hope these a re good questions?

Peter

On Thu, Jan 8, 2015 at 2:22 AM, Ega Wachid Radiegtya < notifications@github.com> wrote:

of course you can add "post/whateverActions" like alanning:roles, for example: posts/upsert, posts/viewAllMyGirlFriend, posts/favourite etc. So I don't think meteoris need to be integrated with alanning:roles, because all what alanning:roles can do, meteoris did. And I'd like meteoris developer to focus on code, just relax about roles without adding single code and just using roles UI easily.

about ongoworks:security I'll try to studying it first. :)

Thanks

— Reply to this email directly or view it on GitHub https://github.com/radiegtya/meteoris/issues/20#issuecomment-69154556.

_Peter Gerwing _petergerwing@gmail.com petergerwing@gmail.com 403-507-6299 _Box 4125, _Olds, Alberta, Canada T4H 1P7

[radiegtya]

if you want to relate user, actually you don't need to make the relation manually. because meteoris has been create it for You. just use createdUser.profile.name or updatedUser.profile.name in your view. But if you still wanna to manually adding relation, just do this step:

1. open mugen crudss generator
2. set the collection name
3. set the name to "userId" or you can named it to "happyUserId" or whatever (in this case I'll use happyUserId)
4. set the type to string
5. set belongs to collection to "Meteor.users"
6. set relation key to "happyUser"

then generate it..

and it will be automatically creating helpers like this in collection

happyUser: function() { return Meteor.users.findOne(this.happyUserId); },

---

the basic logic is like this

• means anonymous user, so all user including @ and admin or whatever able to use actions which * can used too.

@ means logged in user, so * unable to use @ actions if You don't set the actions for * manually.

example:

• available actions => home, about @ available actions => insert, update

it means that * can access only home and about page/actions. But @ can access all home, about, insert, and update.

so basically anonymous user or * are not there in group. It's available because * means blank in form. if you want to remove * access index and view. just open the role menu. and choose * group, with desirable collection. and just remove index, and view.

Thanks

[radiegtya]

I'll close this for now. If there any bug let me know and just reopen it. Thanks