
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Parallel Development Qliksense
Hello All,
We have to develop a Qlik-sense application . 3 developers will be working on that.
We have came with an approach that all 3 developers will be working on different sheets after the data model is developed and loaded with the same login.
If one one a developers needs to reload the app, the other 2 need to informed.
This is the only approach we found for collaborative development from multiple users ?
Are we on the right path.
Is there any other alternative for parallel development.
What are the challenges you people see in the above approach.
Thanks
Khushboo
- « Previous Replies
-
- 1
- 2
- Next Replies »


- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Khushboo,
Firstly, if you are making use of the same login you will not be able to work on the same app at the same time. The first one who was using the Dashboard would get kicked off. Instead I would suggest you to have One app which has the built Data Model and only then duplicate the app into 3 and Start working separately on the master items and Visualizations.Once the UI part is done. First replicate the Master Items and then copy the Visualizations to the master App.
This way It could be easier in my opinion!
Thanks and Regards,
Sangram Reddy.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi sangram,
Are you sure as i have done a POC on this.
Using the same login on HUB we were able to do changes on different sheets.
Thanks


- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes you can work on different sheets but not on the same sheet at the same time. So if you happen to navigate between sheets it is going to log others out.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ya that i have tested. That is why i mentioned different sheets.
Only thing is whether there is another better approach anyone is following?
Thanks
Khushboo


- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I don't think there is a better way than this.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Why can't you use the built in workflow to facilitate your multi-developer needs?
For example, developer 1 builds the initial app in their My Work location and when ready, they publish their core app to a stream that the other developers have access to. Developers 1, 2, and 3 can now create their own sheets as My Sheets within the app and when they are ready to share them, the sheet(s) are shared with the other developers to review, test, QA, etc... Once the sheets are accepted, they can be promoted as a published sheet which makes them part of the app.
Shared and personal sheets are retained, even if someone republished the app over the original one so they will not be lost from app changes by the original developer.
In addition, if someone attempts to reload the app your developers can keep developing as the app update to the users won't happen until after the reload was successfully completed.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Steve,
Can you clarify this part for me:
Developers 1, 2, and 3 can now create their own sheets as My Sheets within the app and when they are ready to share them, the sheet(s) are shared with the other developers to review, test, QA, etc... Once the sheets are accepted, they can be promoted as a published sheet which makes them part of the app.
Specifically I feel like there are 3 concepts here: And I'm lost
- Publishing an app, I'm comfortable with it.
- As you say, "Sharing the sheet"; how to do it?
- As you say; "Promoting the sheet" aka "Publishing the sheet"; how to do it?
Trying to find answers to my own question:
- Qlik Tips: Promote a Qlik Sense sheet from Community to Approved
- Here Stephen exploits that "Published" is just a setting in a database as described in the documentation; "The QRS sets the app object as published in the repository database."
- Specifically "AppObjects" is the table; "Published" is a column, "Approved" is another, and a given App Object - a row - can have values like true or false in these two columns.
- Qlik sense - how to approve app objects
- Qlik Sense QMC Utilities
- https://help.qlik.com/en-US/sense/2.0/pdf/Publishing%20Apps,%20Sheets%20and%20Stories.pdf
So I'll avoid using Steve's words from above.
I'll use "Approved" and "Published", as those things are definitely columns on sheet objects, with values like "true" or "false", as shown here:
Publishing should be easy:
https://help.qlik.com/en-US/sense/3.1/Subsystems/Hub/Content/Publishing/publish-sheet.htm
Despite that, I can't do it.
I feel like I (User: nathanielanderson) have Publish (Action: Publish) permissions to the Sheet "International Template Nate's Dev" (Resource of App Object), as shown here:
And yet, I can't seem to publish that sheet, as shown here: (screenshots show the second technique described on Qlik Sense help) but neither technique works for me.)
.png)

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all,
I have a solution, by using custom properties and security rules in order to be able to work multiple developers on one unpublished app. I have put this in my blog:
http://www.qlik-blog.com/files/aaa5fa62fb65b2841898f5d04fc27c69-3.html
Shortly, you define Custom properties and put and object and users related to the app into it. In the security rule you define, you provide the rights. This works even for unpublished apps, which is superior.
Regards,
Oktay
www.qlik-blog.com

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Oktay, thanks for your post. In your example your rule requires 2 custom properties. Is it possible to use just 1 Custom Property; i.e. just resource.app.@Bereich = Bearbeitung ? I guess that is possible; in fact I could use any techniques as long as the "Condition" clause can target the apps I want to "share" among developers?
Also where will the app appear in my hub? Will it still be in "My Work" section of the hub? Can the app be in "published=true" state for this to work?
What's the difference between resource.@Bereich and resource.app.@Bereich -- shouldn't just resource suffice?
EDIT
OK after some experimentation I have answers for my questions:
- Is it possible to use just 1 Custom Property; i.e. just resource.app.@Bereich = Bearbeitung ?
- Yes, 1 condition is fine; you can even use no conditions at all (the broadest possible rule?). My current rule uses only one condition: is resource.@AppCollaboration="true". This means any/all users will be able to edit these apps! I know that may be a security risk.
- Also where will the app appear in my hub? Will it still be in "My Work"
- Yes, it can only appear in "My Work". The moment it's published, it won't appear in "My Work", but you can't edit /update a published app anyway.
- Can the app be in "published=true" state for this to work?
- No it cannot be published; the moment it's published, it won't appear in "My Work", and you can't edit /update a published
- What's the difference between resource.@Bereich and resource.app.@Bereich -- shouldn't just resource suffice (no need resource.app)?
- I don't know the difference. Here's my guess: resource refers to the resource in question, whereas resource.app refers to the app linked to the resource in question. Some resources (like Data Connections) are integral parts of an app, so we can indirectly refer to their app via resource.app. Am I right?
- Yes, resource.@Bereich suffices. ("Bereich" is the name of Oktay's custom property, of course you would use your own custom property here, like resource.@CustomProperty, or in my case, resource.@AppCollaboration = "true")
- In fact, resource.app.@Bereich does not work for me, I must have resource.@Bereich! As I speculated above, resource.app probably refers to the app linked to the resource. Since I am interested in the resource itself being an app (vs the resource having an app), maybe that's why resource.app does not work, but resource does work.

- « Previous Replies
-
- 1
- 2
- Next Replies »